Is there a way in the UI or configuration to limit the ability of a user to send an application twice for the same resource?

[moisbo]

Hi!

We are trialing REMS for a couple of projects and it is looking great.

We are considering the following use case:

• A user can only apply to a resource if the state of the application to a resource is not Applied / Approved / Rejected.

Is this something we can achieve with configuration?

Many thanks for the great work!

[Macroz]

Hi,

Unfortunately, there is no such feature at the moment. However, it would not be such a big change. I'll make a note about this on our board.

To consider this feature, it would need to be defined in a bit more detail. I believe what you are after is that there can only be one application of a certain resource currently in progress. So one at a time.

An example of where there can be another is when someone has had an application already approved, they may want to apply again with slightly modified details, to e.g. add a new team member, or add more resources to the "project" they have. I think this would be fine to allow. But, if there is an application that is being processed already, it could be useful to prevent another new one from being sent, before that has been processed. Does this sound reasonable?

Another detail would be that do the applicants/members have to be identical for it to be considered an application for the same resource? Also if there are two catalogue items for the same resource, does this apply to the resource or only to catalogue items. There was a previous use case we considered, where the resource could be offered under two different licenses, e.g. for public/non-profits vs. commercial use.

One of the fundamental ideas of REMS is that the handler is a powerful user, that is allowed to do many things, for REMS to be as flexible as possible. So let's say the handler is an assistant whose job is to see the application succeed. Therefore in some cases we have chosen not to implement a limiting feature, to allow the handler to be the one who decides if something is acceptable for some case or not. Like it could be that the application has some "wrong answers", but it could be that it is acceptable anyway. This is useful also for REMS to be relevant to many organizations with different needs, without being difficult to maintain or configure due to a lot of customization options. The more rules there are, the more inflexible a processing system is.

I would guess that our current production instances don't have a problem, if an application is sent twice for the same resource by the same people. It will likely be the same smallish team of humans who process both applications, and would understand that the other is a duplicate, latter overrides the former, or whatever it means for their organization. On the other hand, if there is a lot of automation desired wrt. application processing, or even application creation automatically, such a feature could be useful. In the end, if the application is approved, an entitlement will be given for each member, and there shouldn't be a problem if it is given "twice".

[Macroz]

Created issue #3124 to track this idea.

[moisbo]

Hi Macroz, thank you for your reply.

I personally agree that a handler should be a power user. What do you think then about the rejecter-bot when handling applications rather than entitlements?

Say if we enable the approver-bot and the rejecter-bot in a workflow. Once we place a user in a black list a following application will be rejected. However previous entitlements for the same resource will not be affected. Then someone needs to revoke all of the entitlements for X resource for this blacklisted user.

Could we create our own bots to achieve this? We were considering also just to have a crontab to cleanup this with the rest-api. Maybe it is cleaner with a bot? Note: I place this follow up question here because it is somewhat related to the fact that one user can apply twice to the same resource.

Cheers,
Moises

[Macroz]

Hey,

If you add a user to the black list, then all the applications the user is member of, that have ever been submitted, will be considered for revocation. So it's not just the future applications. The rejecter-bot must be a handler of that application for this to work, as usual.

Maybe the documentation could be clearer here, also the code is slightly more indirect than it needs to be. The intent is that the person is not trustworthy, so they should have no current entitlements anymore.

I believe this is what you wish?

As for the more generic question about bots and integration. Creating automation is intended to be supported well. Everything that is done by the REMS UI is done using the REST API so it should be able to do pretty much everthing already. We call these bots as they work quite like handlers, just automatically, and it's a nice way to explain the concept. It's possible to build one externally by just using the API, perhaps also listening to the event notifications or at least polling the state sometimes (both work). If there is some detail in the API that prevents you from implementing such yourself, or makes it very inconvenient, we'd be happy to fix that.

These bots we have implemented, we have chosen to integrate into the REMS core because

1. they are generic enough to be of use for many instances,
2. they are created by us and
3. they don't then require an additional deployable component, which can be a complication.

There is one example of an external processor / bot here
https://github.com/CSCfi/rems/tree/master/resources/addons/bona-fide-pusher

Hope that answers your question.