Upon access approval in REMS, DAISY creates 4 access objects for given user

[vildead]

This might be issue related to our current setup. But the API receiving request from REMS should be inspected.

[marikapop]

@vildead can you add a DAISY screenshot with multiple access objects? Or remind me which dataset it was (I checked PRECISESADS, it doe snot have multiple objects).

[marikapop]

It happened for Josie for PRECISESADS

[neoflex]

so, I was able to reproduce the issue and it seems that the following happens:

• when daisy receives the call from REMS, it triggers a re-synchronization of users accounts from keycloak
• this takes too much times and as a result the request times out (but execution actually continues). Timeout is hardcoded to 2.5s in REMS for this request
• REMS considers then the call as failed and will retry it, which will result in multiple access created in daisy.

I propose to implement the following:

1. daisy, when receiving the call from rems, should first check if an access with the exact same information exists, if it does, just return a 200 so that rems sees it as a success
2. check if we can safely avoid a doing synchronisation when the call is received in daisy and instead set up a scheduled task to run the synchronisation

[vildead]

I agree.

1. If an access exists, the fields can be updated (expiration date and REMS application ID in the comments).

[neoflex]

When checking if an access already exists, should we take into account only accesses that were automatically granted? For instance, if there is already an access, in active state, manually granted, and we receive a request from REMS to grant access to the same user and same dataset, what should we do? create a new access independently of the previous one, update the previously manually created access?

Another question that rose during implementation, what fields should we update exactly if identified that an access already exist and we don't want to create a new one (notes, granted_on, created_by, grant_expires_on)?

[marikapop]

If we found that access for the same user to the same dataset has been manually created, I would propose to

1. terminate this manual access by date
2. add note "terminated by REMS due to a new access request by date" This will give us a single valid access object per person at any time point and keep all information about previous accesses.

Do you grant access base on status of access object or expiration date? This will influence the necessity to change expiration date of manually created access.

Valentin, could you please specify your last question? Are you asking about the same situation: REMS found manual access already exist? Or the situation when REMS finds existing REMS records?

[marikapop]

@neoflex I cannot assign people. I hope you will get a notification due to @

[neoflex]

here is a summary of what we discussed with @marikapop. When a new request from REMS arrives:

• check if there is already an active request with the same data (same dataset, same oidc_id, same expiration_date) also created automatically. If so, just ignore the request, returns a success response to REMS. Stop.
• if we are not in the case above, check if there is already a manually created access, active, for the same dataset and same user. If so, mark this access as terminated and add a note explaining it was terminated because of a newer automatically granted access.
• Create the new access