This issue was automatically marked as stale.

This issue was automatically marked as stale.

@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.

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.

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)

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.

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

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?

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