Bug 142753

Summary: Add undo functionality to assigning/removing Tags and Labels
Product: [Applications] digikam Reporter: Viesturs Zarins <viesturs.zarins>
Component: Tags-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: andrew+kdebugs, caulier.gilles, jens-bugs.kde.org, rwijtvliet, ThomasBleher
Priority: NOR    
Version: 0.9.1   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Viesturs Zarins 2007-03-09 18:34:40 UTC 
Version:           0.9.1-rc1 (using KDE KDE 3.5.6)
Installed from:    Gentoo Packages

My main activity at album view is assigning tags to images.
It would be nice to have undo/redo functionality for managing tags.
Comment 1 Arnd Baecker 2007-03-12 08:36:40 UTC 
Yes, this would be great.

On the technical side, this might be non-trivial: while
I could imagine that on the level of the data-base this could
be done quite easily, this is more involved, when changes
(i.e. tags, comments, ratings, ...)
are directly written into the exif/iptc of the images.
So for any operation changing an image: 
for each image the contents of each changed entry has to be 
memorized.
Comment 2 caulier.gilles 2014-08-30 08:22:49 UTC 
*** Bug 330406 has been marked as a duplicate of this bug. ***
Comment 3 Jens 2015-09-03 09:41:04 UTC 
Would it be feasible to allow undo of such operations (editing metadata) if and only if direct modification of image files is disabled? The implementation could maintain an "undo" database table where a SQL string is stored for each operation that would undo exactly that operation. (Or a more structural approach, storing the type of operation including previous values).

If sidecar files are used, a backup file could be created upon modification.

I am also sorely missing undo for image modification in Digikam and I would be content with fiving up direct image file modification.
Comment 4 Maik Qualmann 2021-11-13 07:02:13 UTC 
*** Bug 445405 has been marked as a duplicate of this bug. ***