-
Notifications
You must be signed in to change notification settings - Fork 188
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
Locking a distribution-set or software module does not prevent it from being deleted #1778
Comments
Shouldn't locked DS be deletable? Otherwise, they shall be unlocked explicitly before deleting. Which, could be a little bit confising. |
Signed-off-by: Marinov Avgustin <[email protected]>
Signed-off-by: Marinov Avgustin <[email protected]>
Signed-off-by: Marinov Avgustin <[email protected]>
Signed-off-by: Marinov Avgustin <[email protected]>
IMHO it is more confusing when I can delete a locked DS. Also: Even when only soft-deleted, the user cannot restore the DS. Additionally: As we distribute the DS/SWM via "offline-updates" in the system-update use-case, there is a time-span between releasing the system-update definition and the first returned update-report where no action exists and the DS would be potentially be full-deletable which in turn will corrupt the released system-update-definition. |
I still think that protection for deleting a locked DS shall be made on UI level .. lock means "non-functionally modified" - so you know what exactly has been installed and that the same version is installed everywhere. However, if you want to delete it and you are not interested in using already installed DS - you are free to go ... If you want any protection - to warn user - "hei, it is installed / used somewhere" - it is up to UI or different functionality - not lock related I don't get exactly the offline update use case but it seemed that again the UI could warn about 'locked' status if needed. Also, if you do offline install you may somehow define the DS together with the first feedback - if the device doesn't need to know in advance the id of the DS it applies. Anyway, if there is need of "delete protection" I'm not sure it's part of lock semantic. Any other opinions? |
I agree with forbidding the deletion of the SM of a locked DS. However forbidding deletion of a locked DS does not make sense to me. |
You can delete locked SM - if it's not a part of locked DS :-) |
You can delete locked SM - if it's not a part of locked DS :-) - Yes I think you got my point and didn't specify "from locked DS". Obviously if we stick to the above patter this should remain as is. |
Signed-off-by: Marinov Avgustin <[email protected]>
Observed behaviour
We recognized, that a locked DS/SWM still can be deleted.
Assumed desired behaviour
In order to avoid undesired changes the locking mechanism should also prevent the deletion (not only the modification) of a DS/SWM.
The text was updated successfully, but these errors were encountered: