New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require a community when uploading #183
Require a community when uploading #183
Comments
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. Because of this, it is not easy to control the behaviour of the Is it acceptable to keep the |
Thank you for the detailed explanation @ntarocco TL;DR Regarding the implementation, here are our preferences and requirements at KTH:
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.
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? |
If not included in v12, it will be part of a minor release, e.g. v12.1 |
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
This issue:
closes permissions: records always in community feature invenio-rdm-records#1719
closes ui: Require records community invenio-app-rdm#2642
resolves assets: Fix modal err msg & visibility on remove invenio-app-rdm#2201
resolves widget: fix error message content 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.
The text was updated successfully, but these errors were encountered: