-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Database cleanup (remove obsolete fields) #3032
Conversation
a0114cf
to
b6cf7dd
Compare
8362df0
to
d91b93d
Compare
187ec3f
to
d6b50aa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bravo! 🤩
bc_obps/registration/utils.py
Outdated
@@ -126,7 +124,7 @@ def custom_reverse_lazy(view_name: str, *args: Any, **kwargs: DictStrAny) -> Uni | |||
return reverse_lazy(f"{DEFAULT_API_NAMESPACE}:{view_name}", *args, **kwargs) | |||
|
|||
|
|||
def set_verification_columns(record: Union[UserOperator, Operator, Operation], user_guid: UUID) -> None: | |||
def set_verification_columns(record: UserOperator, user_guid: UUID) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are now using this in one place. Should we move it there or create a function for it under the UserOperator service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooh good point! I'll check with Reporting first - I wonder if they'll have a need for this function, in which case it would make sense to keep it somewhere generic.
b663aa7
to
bed6256
Compare
@andrea-williams Created this ticket for the remaining work: #3121 |
bed6256
to
d4f36f3
Compare
…m Operation model
…cols from Operation & Operator; removed is_new from Operator
Signed-off-by: SeSo <[email protected]>
d4f36f3
to
7ab42df
Compare
Card: #2229
Operation model:
opt_in
field (leftover from Reg1; no longer needed now that we store registration purpose)operation_has_multiple_operators
field from database (is now inferred based on length ofmultiple_operators
array)verified_by
andverified_at
fieldsOperator model:
verified_by
andverified_at
fieldsis_new
boolean field - no longer needed because we internal users no longer need to explicitly approve the creation of new operatorsRemaining work:
status
column fromOperator
model once we have decision on what to do with existing operators that have a status of "Draft" or "Pending" in prod