You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After feedback from contributors, ABRS would like to explore an enhancement where all Edits to an existing profile are automatically set to Draft Mode when the user is an "Author". This could be something in the User Access Levels control that specifies whether authors should be restricted in some way so that it is customisable for each collection.
The rationale is two-fold:
It prevents contributors forgetting to turn on draft mode when they are making a major revision. We have had one example where we have a draft manuscript with yellow highlighted text etc automatically get published because they forgot to set it to draft mode.
Although we have restricted access to the platform, some authors may not be 100% honest about the profiles that they are editing and may vandalise or provide unauthorised edits to a profile outside of their agreed scope.
I would think this would need to be done within a scoped piece of work such as a sprint, my reasons are:
• This is not a currently configurable option and would require development, testing and production release
• It is an enhancement to existing functionality, not a critical bug, so we wouldn’t want treat it as a “hot fix” with the associated risk of not testing it properly
• We have some users who don’t generally lock profiles for major revision when they are editing, so I think this would need to be a configurable option similar to the option to automatically lock new profiles for major revision
To allow for some collections with the function set this way and other collections without, I think the solution would need to include:
Ability to set option for collection on edit configuration page – basically the user interface (UI) to set option
Functionality to automatically lock the profiles for major revision when editing – this is the back end working in this manner
When this option is selected, change the UI when a profile is in edit mode to remove the option to lock for major revision, as this will already be the case.
We’d need to developer input to estimate this with any reliability. The UI changes (1-3) would likely not take too long, but the actual functionality would depend on whether we could reuse code for locking new profiles, or whether we’d need to write that from scratch. And we would need to thoroughly test this for both collections using the new function and collections that don’t.
The text was updated successfully, but these errors were encountered:
After feedback from contributors, ABRS would like to explore an enhancement where all Edits to an existing profile are automatically set to Draft Mode when the user is an "Author". This could be something in the User Access Levels control that specifies whether authors should be restricted in some way so that it is customisable for each collection.
The rationale is two-fold:
Below is the correspondence from @RobinaSanderson:
I would think this would need to be done within a scoped piece of work such as a sprint, my reasons are:
• This is not a currently configurable option and would require development, testing and production release
• It is an enhancement to existing functionality, not a critical bug, so we wouldn’t want treat it as a “hot fix” with the associated risk of not testing it properly
• We have some users who don’t generally lock profiles for major revision when they are editing, so I think this would need to be a configurable option similar to the option to automatically lock new profiles for major revision
To allow for some collections with the function set this way and other collections without, I think the solution would need to include:
We’d need to developer input to estimate this with any reliability. The UI changes (1-3) would likely not take too long, but the actual functionality would depend on whether we could reuse code for locking new profiles, or whether we’d need to write that from scratch. And we would need to thoroughly test this for both collections using the new function and collections that don’t.
The text was updated successfully, but these errors were encountered: