Support locking objects en-masse to prevent ad-hoc changes in restricted environments. #7877
Closed
3 tasks done
Labels
notable_change
A change which should be noted in the changelog
type:enhancement
verified
Tested or intentionally closed
Comments
This was referenced Oct 9, 2024
Testing NotesTest instructions are provided in the issues linked above. They should be executed in the order listed above. |
charlesh88
added a commit
that referenced
this issue
Oct 10, 2024
|
Front-end changes pushed and testing notes in #7878 updated. |
akhenry
added a commit
that referenced
this issue
Oct 10, 2024
* Script for locking an object tree * Show lock button if locked * Do not allow properties editing of locked objects * Remove package-lock.json * Added p-debounce * Allow duplication of locked objects * Better user feedback * Add semaphores to prevent file handle exhaustion * Leverage official Apache Couch library - nano. Clean up dependencies. Default to environment variables for couch config. Simplify batching mechanism to make it synchronouse * Added lock user attribution * Remove unused code * Modify open script for adding auth design doc * Added script for creating auth design doc * Add css class for disallow unlock * Add user attribution to lock button * Fix import * Typo * User it was locked by, not current user. Wow. * Closes #7877 - Front-end sanding and shimming: displays <span> instead of button when domainObject.disallowUnlock. * Fixed bug where lock is shown even if object is not locked --------- Co-authored-by: Charles Hacskaylo <[email protected]> Co-authored-by: Jesse Mazzella <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Certain of our operational environments require a subset of domain objects to be immutable to regular users. For example, displays that users are trained on should only be modified following a change-management process, and should not be modifiable ad-hoc during live operations.
Describe the solution you'd like
Open MCT already supports object locking. This capability could be leveraged as a mechanism for preventing changes in operational environments by enforcing object locking on the server-side (ie. in Couch DB), and disallowing users from unlocking them.
Implementation is in a single PR, but I've split this task into multiple GitHub issues to allow us to split up testing more effectively.
In all cases the existing user-locking functionality should be retained.
Describe alternatives you've considered
A second read-only couch database. This requires more widespread changes to Open MCT and the attendant risk associated with large-scale changes to our persistence API.
The text was updated successfully, but these errors were encountered: