Invited member has very little application permissions

[sherzinger]

Hello,

We used the /api/applications/invite-member API to invite someone to an application, however it seems that being a "member" of an application gives one almost no rights, short from seeing the application state.

Is that intentional? If so, is there any way to transfer "ownership" or grant additional privileges for an application?

[Macroz]

This is so far completely intentional. The inspiration is a handling process where typically one member of a research team acts as the representative of the team i.e. the person known as the applicant in REMS. The members only have to accept the licenses, and can of course see the state, but finally will get the same permissions once the application has been handled.

It has been speculated that at some point there may be a need for a transfer of ownership to another member, if the applicant leaves the research team. However, it could be modeled also as a new application based on the existing application.

What is the use case you are thinking of? Technically it would also require some additional work to be enable multi-user edits of the application form at the same time.

[sherzinger]

Hey @Macroz , I'm discussing this use case with @jaakkocsc currently, but I'm posting it here too. Maybe you have additional insights:

---

Ada System: Contains real data for data exploration
REMS: Contains studies, for which we accept sample requests

1. User logs into Ada and explores a data set
2. User wants to make a sample request for 2 samples (out of potentially thousands)
3. Ada, via a REMS service-user “ada-service”, creates an application and partially pre-fills the form based on the previous exploration
4. Ada, via a REMS service-user “ada-service”, invites the current user to participate in the pre-filled application
   ++++ Up to this point everything works fine ++++
5. User (now in REMS as a member of the application) completes the form and submits it for review

---

We found an alternative route by "impersonating" the user, using an API key which is valid for all users and by "assuming" the ID which will be used in REMS. It's far less elegant and has some problems, such as that the user mapping between Ada and REMS requires the same IdP to be used on both sides, otherwise the OIDC user id can't be mapped securely by Ada.

That's why an email/invite based approach is much more elegant here.
Something like this:

POST /api/applications/transfer-invite?application-id=22 {
	“new-application-owner-email”: “sascha.herzinger@uni.lu"
}

It’s also not a too far fetched use case having someone else “take over” the application process. E.g. PI is sick/busy/on vacation/on travel …

[Macroz]

Hi, thanks for the clarification.

What do you mean by prepopulating the application? A REMS application can be linked into with a URL like /apply-for=x,y,z if you only need to prepopulate the resources / catalogue items that are applied. When the user follows this link they need to authenticate and they will get a blank new application. If you need to fill in more data then yes you should use the API because so far you can't provide any more details.

There is currently no possibility of inviting the original applicant or transfering ownership. Impersonating the user is the way it is thought to go mostly, if another system acts on behalf of a user. The possibly complicately generated ID of the IdP must be known in that case beforehand, which may not be always practical.

I'm sure there are several avenues to solve these problems.

[sherzinger]

Hey Markku,

by pre-filling I mean that Ada has some information that it submits to REMS to the application form.
In the above example it could be certain data regarding the 2 selected samples.

As you said, "reverse engineering" the IdP ID is not very practical, which is why an email invite based approach is so tempting, because the user can decide what IdP to use, and no mapping has to be done on server side.

[sherzinger]

And as Jakkoo told me, we're definitively not the only one with this use case. Extending the API (as suggested above) would really help in any setup where REMS is connected with other services I feel.

What do you think?

[Macroz]

And you are sure that you need to store this extra data regarding the selected samples to the REMS application? If that is form data in the application then the applicant can choose to change it?

[Macroz]

There are many many reasonable extensions and I'm trying to understand what the business case is so that I can provide the best solution to it.

[sherzinger]

In our use case the user can either go directly to REMS and make their request or they can go to Ada first.
Ada is a platform for data exploration, so while working through the data the user might find a group of interesting data points for which he/she would like to make a request in REMS. That can be 2 ids, it can be 2000 ids, it can even be a data matrix, for instance if samples are stored at different biobanks.

The fact that this information is rather volatile and can potentially be rather large is why we submit this information as an attachment to REMS by the system, not by the user itself.

I hope this helps to understand our situation a bit better

[Macroz]

I think we should include a role in the invitation link. This is more or less required for the reviewer invite too. I think we can then include an invitation for an applicant then and most of your problem would be solved. Ideally we would also have a handler invitation.

[sherzinger]

🎉 Thank you very much

If you don't mind me asking: What role would the invitee have in the use case above? Wouldn't you have to extend the role system to include an application-owner, an application-co-editor or something like that?

[Macroz]

All the current roles can be made invitable with some adjustment. But so far I think there will be one applicant and others are members. And we can think about extending member actions later.

[Macroz]

I will be working on a proof-of-concept for multi-user editing, so that applicant and members could edit the application together, even at the same time. This should solve some part of this issue.

[Macroz]

Here is an idea issue about pre-filling applications #3049