Per-request permission management

[lanseg]

Issue #379

Purpose: per-request user ownership, make it possible for one operator to make a single request visible to another operator, even if the second operator is not an owner of the parent process.

Behavior:

1. Admin user sees all requests, no matter what users or groups are configured for the request or process
2. User can see or modify request if any of this applies:
   1. User or user's group is added to a Request
   2. User or user's group is added to a parent Process of this request
3. A request-owning User can modify request-owning users and groups.
4. After the user removes themselves from the request owners list, per-process ownership rules apply.

[benoitregamey]

Thank you for the contribution, will look it next week.

[lanseg]

Hi! Any progress on the pull request review?

[benoitregamey]

Hi! Any progress on the pull request review?

Not yet, I didn't have time. I'll keep you updated when it's done. Thanks for your patience

[benoitregamey]

Hello!

I’ve tested your PR and everything works perfectly — great job!

From our side, we find this feature interesting and would like to merge it into the main project. However, in its current form, it changes the default behavior of the application, which could be problematic for users who rely on strict ACL configurations.

To be merged, the feature would need to be disabled by default and enabled via a toggle. This could be done either at the application level (through the main settings), or ideally at the process level (for example, with a toggle next to the assigned operators).

What do you think? Would it be possible to implement this change?

[lanseg]

Hello!

I’ve tested your PR and everything works perfectly — great job!

From our side, we find this feature interesting and would like to merge it into the main project. However, in its current form, it changes the default behavior of the application, which could be problematic for users who rely on strict ACL configurations.

To be merged, the feature would need to be disabled by default and enabled via a toggle. This could be done either at the application level (through the main settings), or ideally at the process level (for example, with a toggle next to the assigned operators).

What do you think? Would it be possible to implement this change?

Yes, it's possible to hide the controls and the related code under the feature flags. But the schema-reated changes will stay (e.g. many-to-many tables will be in the database, but they will be empty)

[lanseg]

Added a feature flag that blocks per-request ownership.
The ownership change was too invasive so it was too difficult to hide the whole change in all files behind this flag. Instead, this flag enables and disables per-request ownership editing, not the ownership extension itself.

• Working use case (expected): feature is disabled by default, but user can enable it from the properties file.
• Potential issue: an user enables feature and then changes their mind. In that case ownership/visibility rules will still apply. Could be done by clearing all the request <-> user/group tables if the flag is set to false.

[benoitregamey]

Okay, that seems pretty good to me !

Since I'll meet the Extract Users Group next week on Monday, I'll discuss with them if it's okay to merge incoming PR if the default behaviour of the app is not changed.

I keep you updated !

Thanks for the contribution !

[benoitregamey]

Please, rebase your branch onto the master and make all tests pass. FYI, there is now 3000+ tests implemented and integration tests are failing with your PR.

Thank you for your understanding and patience