Decider workflow - Request decision via email :forbidden error

[mpestle]

When using a decider workflow, as handler, if I attempt to "Request decision - via email", it throws a slightly cryptic :forbidden error. This is possibly by design, since the decider-workflow permissions do not include invite-decider. This is presumably because the decider is more powerful than a reviewer, and forbidding this option is a sensible security decision. But I feel that if it is forbidden, we should not see the option to Request decision via email. And is there a reason why the default workflow includes the invite-decider ability but not the decider workflow?

I can hide that "#invite-decider-action-button" using extra-styles.css, but this probably will hide it for all workflow types (not just decider). If I really want to be able to do this, I believe that I could add the permission to the application/model.clj file and rebuild. I would prefer to use that as a last resort, since I don't really want to diverge from the main code trunk.

I'm wondering if maybe a better option would be a configuration parameter that will override the default more secure option of not permitting invitation of deciders and allow it, and thus make visible the option of "via email" in the "Request decision" button.

Or maybe such an option already exists and I haven't found it yet? Apologies for the time wasting if so.

[meericsc]

Thanks for reporting this. It looks like it might be a bug, but we need to investigate it a bit more. If it's by design, it should be clearer in the UI like you said. I will get back to you on this.

[meericsc]

I discussed this with our team, and we couldn’t find any indication that this behavior was intentional. Since a handler can already invite themselves to decide as an existing member, preventing them from using the email invitation doesn’t really change their permissions in case they wanted to misuse their rights.
Interestingly, the email invitation feature was added around 2020, and this is the first time the issue has been reported, and we haven’t noticed it ourselves either.
I’ll add this to our board to be fixed. Thanks!

[mpestle]

Ah, great, thanks. We were implementing the decider workflow so that the handler didn't have the ability to approve and I had noticed the ability of a handler to just invite themselves as a decider and then approve. This is the case even if an explicit rule is added to the workflow denying the handler the ability to approve. I was wondering if the logic deciding the ability to approve might be made more conservative, so that if any rule prohibits a user from approving, then they can't approve. Else if any rule allows approval, you can approve. Else you can't.

The end goal would be that a decider can be confident that only deciders can approve. I noticed another suggestion regarding the implementation of a smaller "pool" of deciders presented for selection in order to avoid name ambiguity and errors where large user populations are in play. Maybe there are some design decisions to consider there that would address both issues.

Look forward to your resolution here, and in the meantime we will stylesheet out the "Request decision - via email" button.

[meericsc]

Yes adding a rule doesn’t work, because handler gets a decider role via the invitation. I think you have a valid use case, but unfortunately there are several ways to work around the restrictions if someone is determined to do so. For example, if multiple identity providers are used, a handler could invite their second identity as decider because REMS currently does not recognize multiple identities can be the same person. Because of this, our current approach is to rely on logging everything rather than trying to block every possible misuse. That way, if someone abuses their rights, there’s a clear audit trail. For now, implementing more restrictions isn’t in our scope, but contributions are always welcome if you’d like to explore it yourself and we will keep this use case in mind.

About the decider groups: the GDI project may have a similar need, but I can’t promise whether it will end up being implemented as part of the project. If the decider group is always the same, there is a workaround, although it’s a bit complicated. You can write a script that sends decider invitations based on application events. There’s an experimental change state feature that sends a :application.event/processing-state-changed notification. Your script could listen for that event and then invite a predefined decider group automatically using this endpoint:
https://rems-test.2.rahtiapp.fi/swagger-ui/index.html#/applications/post_api_applications_invite_decider
If you're interested on trying this solution I can provide more information about it.