Require a community when uploading

[Samk13]

Is your feature request related to a problem?

Organizations may require at least one community to be associated with a record. Currently, there is no configuration option to enforce this constraint.

Describe the solution you'd like

• Add a new configuration option that prevents users from deleting all communities in a record, except for the last one. By default, this feature should be off and can be activated in an instance by adding the following configuration:

  RDM_RECORD_ALWAYS_IN_COMMUNITY = True

• When this configuration is set to True, users should still be able to remove communities, but not the last one, ensuring that there is always at least one community associated with the record.
• Assert that users are unable to directly publish a record without going through a community submit process. In this scenario, the community manager would be responsible for publishing the record. This can be achieved by disabling the "publish" button based on the configuration value and ensuring that users can only submit the record for review to a community manager. This issue: closes https://github.com/inveniosoftware/invenio-rdm-records/pull/1719 closes inveniosoftware/invenio-app-rdm#2642 resolves inveniosoftware/invenio-app-rdm#2201 resolves inveniosoftware/react-invenio-forms#202

Describe alternatives you've considered

An alternative solution could involve implementing a more granular permission system that allows administrators to define and enforce specific rules for community association. However, this would require a more complex implementation and might introduce unnecessary complexity for most use cases.

Additional context

This feature request is related to the issue of disabling the "publish" button based on the value of a config variable and raising validation errors if the user hasn't selected a community when publishing. Implementing this configuration option will provide organizations with more flexibility in managing their records and community associations, as well as ensuring that the community managers have control over the publishing process.

This feature is related to CERNDocumentServer/cds-rdm#55 We can bring up the topic of introducing custom roles in place of granting full admin access for community creation. As community managers, we're interested in limiting their permissions to manage their respective communities only, rather than having complete control over the system. We discuss this further and explore potential solutions in separate issues when this one is merged.

[github-actions[bot]]

This issue was automatically marked as stale.

[github-actions[bot]]

This issue was automatically marked as stale.

[ntarocco]

@Samk13 @tmorrell (and anyone else interested in this feature) I started looking at the changes, and I realized that the implementation is more complex than expected. After our discussion, the agreed solution is to implement this feature via permissions. This means that only configured users/roles via permissions will be able to publish without a community: by default, only super admins. However, this is configurable in your instance/overlay.

Because of this, it is not easy to control the behaviour of the Publish button in the upload form, and disable it when the current user cannot publish without selecting a community. In the upload form, the community selection happens in the UI only, client side, before publishing, and the can_publish permission is checked only after clicking on the Publish button. Currently, there is no implementation that allows permissions evaluation on the UI/client side after an action (in this case, the selection of a community).

Is it acceptable to keep the Publish button always enabled, and return an understandable error after clicking on the Publish button when permission check fails? If not, the implementation will become very complex. If you have other ideas, let me know.

[Samk13]

Thank you for the detailed explanation @ntarocco

TL;DR Yes to the proposed implementation we can go with this approach.

Regarding the implementation, here are our preferences and requirements at KTH:

1. The preferred approach would be to disable the Publish button if the user lacks the necessary permissions to publish without a community, similar to the example we created here. However, if this introduces significant complexity, displaying an understandable error message after clicking the Publish button is acceptable like in here.

2. We need to have a specific role for community managers, distinct from the admin role. This role should allow admins to grant or restrict the community-manager role as demonstrated in the implementation we create here here as community managers or a better naming would be a community-creator should NOT have admin privileges as there role should be limited to create/manage communities only!

3. It should not be possible for a user to remove the last community from a record. This requirement is crucial for our use case as it's been implemented here.

4. This one can be taken in a later step: as the introduction of the GitHub integration, we need to consider changing the current scenario where the repository is been published directly without selecting a community or going through the deposit page. In such cases, the user is not been prompted to add a community to adhere to the publish with a community restriction.

Please let us know if you need any further clarification or how can we corporate on this.

[tmorrell]

I very much agree with the error after clicking the publish button approach. We pre-fill the community via the template, so for a user to encounter the error they would have to actively go and remove the community. An error seems reasonable since it was a result of user action. We might want to document that it's recommended to set a default community when using this configuration.

The other KTH requirements all sound reasonable but I think they are slightly separate from the community requirement (we don't need any of them for our use case)

[zguillen]

We’ve implemented the general requirement of ensuring a community is assigned for every record in a very different approach. It’s been over a year now so I can’t remember all of the technical details but it’s easy for me to show you how the UI works.

1. We’ve overwritten the /uploads/new route to render our own react component that is simply a modal. (NOTE: in our UI we’ve renamed “community” to “project”) We force the user to select a “reviewing project(community)” first, before filling anything out on the deposit form:

2. We POST from that modal to /api/records to create the draft and then PUT to a URL like this using the reviewing project’s id: api/records/zwtga-c9702/draft/review
3. Last, we redirect the browser to the original RDM deposit page with the newly created draft as if the user clicked edit next to a draft (/uploads/zwtga-c9702)
4. Here’s what the draft UI looks like with our customized project (community) UI:

5. I think I remember having to hook into a little bit of the buttons and react state to get the draft’s buttons to render like so (but it wasn’t that much work):

You’re welcome to play around with this UI at https://data.dev.msdlive.org/ but you’ll need to create an account and request to join a project first. I’ll get an email and approve the request if I see any come in.

[ntarocco]

Thanks a lot for the comments and discussion: we will actively work on this in Q2, it is now in our roadmap.

[tzubaki]

For JRC, this feature is needed for the first production release, as we should not allow people to publish out of communities. The solution proposed by Nicola, when the button Publish is still enable, but a meaningfull error message will prevent from publishing is ok. Could this still be included in V12?

[ntarocco]

For JRC, this feature is needed for the first production release, as we should not allow people to publish out of communities. The solution proposed by Nicola, when the button Publish is still enable, but a meaningfull error message will prevent from publishing is ok. Could this still be included in V12?

If not included in v12, it will be part of a minor release, e.g. v12.1