search

eclipse / hawkbit

Eclipse hawkBit™
https://projects.eclipse.org/projects/iot.hawkbit
Eclipse Public License 2.0
453 stars 187 forks source link

Locking a distribution-set or software module does not prevent it from being deleted #1778

Open vigier opened 1 month ago

vigier commented 1 month ago

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.

avgustinmm commented 1 month ago

Shouldn't locked DS be deletable? Otherwise, they shall be unlocked explicitly before deleting. Which, could be a little bit confising. To protect/warn the user to delete assigned DS I think is a responsibility of an UI. There is soft deletion for cases it an locked and installed DS shall be deleted. I think that it would be best if we just forbid deletion SM when it is a part of a locked DS. This will prevent implicit modifications of a locked DS - which I think is the main problem.

vigier commented 1 month ago

Shouldn't locked DS be deletable? Otherwise, they shall be unlocked explicitly before deleting. Which, could be a little bit confising.

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.

avgustinmm commented 1 month ago

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?

strailov commented 1 month ago

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. Deleting a SM from a locked DS is as Avgustin mentioned "modification" of a locked DS and makes sense to be applied. However by applying that I also agree it is a bit confusing for the end user - we cannot delete locked SM, but not DS. It makes also sense to me for the UI to give some kind of a warning about that.

avgustinmm commented 1 month ago

You can delete locked SM - if it's not a part of locked DS :-) it becomes more and more complex. We could say - deletion is a modification - then we may reject deletion also. Somehow, all is about semantics of locking / modification. Also, maybe it make sense to forbid unlock of SM that a part of locked DS - @vigier, @strailov what do you think?

strailov commented 1 month ago

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. It also seems reasonable to forbid unlocking of SM that is a part from locked DS.