Add project tracking via group_events attribute - #581
Conversation
Tracks project changes on each user via a new keycloak attribute. Also includes a management command to initialize this attribute with current project membership, indicating that the events were backdated.
pdmars
left a comment
pdmars
left a comment
There was a problem hiding this comment.
Overall looks good to me. Do we have admin/operator docs on when, and how, to use this command?
I can add some docs in the file. This will just be run once it is deployed for the initial data. It shouldn't be run again. I included it here so that we can reference the implementation if we need to in the future. |
msherman64
left a comment
msherman64
left a comment
There was a problem hiding this comment.
The data we store seems reasonable
My main question is about the details of storing this in a keycloak attribute.
it seems like this is getting appended to a single field?
How long a value can keycloak store?
if we want to query this later, how is this done?
I guess the alternative would be storing this in a portal db table, which also means we need to keep it in sync with keycloak.
| citizenship=None, | ||
| phone=None, | ||
| lifecycle_allocation_joined: "datetime" = None, | ||
| group_events: dict = None, |
There was a problem hiding this comment.
is group_events a dict or a list?
|
|
||
|
|
||
| class Command(BaseCommand): | ||
| help = "Normalize user-supplied institution strings into Institution/UserInstitution models" |
| Args: | ||
| kc_user (dict): The Keycloak user dict. | ||
| charge_code (str): The charge code of the project. | ||
| event_type (str): The type of event ("add" or "remove"). For backdated events, there is also "add_backdate". |
There was a problem hiding this comment.
it could be worth considering storing two timestamps:
audit_time, and event_time, this would distinguish backdated events naturally
The keycloak user API returns this info. We use it already to store if the user has agreed to terms and what institution they are from. It persists forever. The field is a list, but it is serialized as a string if there is only one value. This is how keycloak handles attributes.
Yes, it would be easier to query in portal directly, but it seems more consistent to keep this in portal. We probably should sync this to a reporting DB like we do for events. Right now it is easy to verify this field is accurate, as we can look at any individual user and compare the attributes to their project membership. I do like the idea of audit time vs event time, but I am trying to minimize the complexity to process the data. |
3 participants
Tracks project changes on each user via a new keycloak attribute. Also includes a management command to initialize this attribute with current project membership, indicating that the events were backdated.