Is your feature request related to a specific problem?
A general requirement for the data use declaration form is that the Data use and Processing Activity fields are effectively locked-down in the UI (made read-only) once a data use declaration has been created on a given system. While this behavior is generally the case currently, there's an edge case where the fields are still editable immediately after saving the data use declaration initially, before navigating away from the form.
Although it may be unlikely, if users edit those fields in that state when they are still editable but after saving, they could end up breaking links between any custom fields and the data use declaration, which is a side effect of how our API is implemented (and the reason we want to lock those fields down generally).
Describe the solution you'd like
The fields should be locked down immediately after saving the data use declaration, and stay locked down indefinitely.
Describe alternatives you've considered, if any
In general we'll look to rework the data use/privacy declaration API to not require this constraint, but that's a longer-term effort.
Additional context
Found in doing some 2.12.0 release testing
cc @TheAndrewJackson @rsilvery @mfbrown @Kelsey-Ethyca
Is your feature request related to a specific problem?
A general requirement for the data use declaration form is that the
Data use
andProcessing Activity
fields are effectively locked-down in the UI (made read-only) once a data use declaration has been created on a given system. While this behavior is generally the case currently, there's an edge case where the fields are still editable immediately after saving the data use declaration initially, before navigating away from the form.Although it may be unlikely, if users edit those fields in that state when they are still editable but after saving, they could end up breaking links between any custom fields and the data use declaration, which is a side effect of how our API is implemented (and the reason we want to lock those fields down generally).
Describe the solution you'd like
The fields should be locked down immediately after saving the data use declaration, and stay locked down indefinitely.
Describe alternatives you've considered, if any
In general we'll look to rework the data use/privacy declaration API to not require this constraint, but that's a longer-term effort.
Additional context
Found in doing some
2.12.0
release testingcc @TheAndrewJackson @rsilvery @mfbrown @Kelsey-Ethyca