Bug 331695

Summary: MANAGER : misleading menu entry may lead to unintentionall purging of all tags
Product: [Applications] digikam Reporter: Michal Sylwester <msylwester>
Component: Tags-ManagerAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, veaceslav.munteanu90
Priority: NOR    
Version: 4.0.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 4.3.0
Sentry Crash Report:

Description Michal Sylwester 2014-03-03 09:59:07 UTC
Tags manager "Sync Export" -> "Wipe all tags from database and read from images" is misleading. My understanding is "Wipe all tags from DB and then repopulate DB with data from image files", while subsequent messages (and actual behavior) indicated that it wipes the tags in files as well. 

The next message:
"This operation will wipe all tags from database and will write changes to image metadata.
Do you want to continue?"
seems to be accurate. I managed to wipe my tags this way by not reading the second message carefully and trusting my understanding of the first one (good I had backup).

Reproducible: Always

Steps to Reproduce:
1. Open Tags Manager
2. Select "Sync Export" -> "Wipe all tags from database and read from images" 
3. Confirm and wait
Actual Results:  
Tags from DB and files are wiped

Expected Results:  
I'm not sure what's the expected scenario, as I can imagine both ("Wipe tags from DB and files" and "Wipe tags from DB and restore from files")

It seems that some ITPC tags were not wiped, after running "Re-read metadata from images" some tags reappeared.
Comment 1 Veaceslav Munteanu 2014-03-03 12:04:52 UTC
Yep, I can reproduce this. 

I think it's because Metadata sync is enabled in menu. Will try to fix, I will add some code to disable tag sync when tags are wiped from database.
Comment 2 caulier.gilles 2014-03-03 12:22:23 UTC
Git commit abd9f93fa2a22a1385f32094740466571a0587da by Veaceslav Munteanu.
Committed on 03/03/2014 at 14:15.
Pushed by munteanu into branch 'master'.

Fixing bug 331695: Disable temporary wipe tags option to avoid accidental deletion of tags from image metadata

M  +3    -0    digikam/tags/tagsmanager/tagsmanager.cpp

http://commits.kde.org/digikam/abd9f93fa2a22a1385f32094740466571a0587da

diff --git a/digikam/tags/tagsmanager/tagsmanager.cpp b/digikam/tags/tagsmanager/tagsmanager.cpp
index 4300c2b..47ba281 100644
--- a/digikam/tags/tagsmanager/tagsmanager.cpp
+++ b/digikam/tags/tagsmanager/tagsmanager.cpp
@@ -692,6 +692,9 @@ void TagsManager::setupActions()

     wipeAll->setHelpText(i18n("Delete all tags from database. "
                              "Proceed with caution."));
+
+    /** BUG: Disabled temporary, will cause all tags from images to be lost **/
+    wipeAll->setEnabled(false);

     connect(wrDbImg, SIGNAL(triggered()),
             this, SLOT(slotWriteToImg()));
Comment 3 Veaceslav Munteanu 2014-03-03 12:24:45 UTC
Gilles, this is not the fix :)) 

I only disabled it (to avoid someone running to the same problem), until I will find a way to fix it :)
Comment 4 caulier.gilles 2014-03-03 12:46:59 UTC
yes, i seen, but at least your commit must be CC in bugzilla entry for info

Gilles
Comment 5 Veaceslav Munteanu 2014-03-09 15:41:11 UTC
author	Veaceslav Munteanu	
Sun, 09 Mar 2014 17:33:20 +0000 (19:33 +0200)	
committer	Veaceslav Munteanu	
commit	2901c5564ccbbd6999ab8847c39870005c636fc4	

Bug 331695: Rework TagsManager's wipe all tags to delete database only. Reread can be done via another menu entry. Small operations are more flexible 


http://quickgit.kde.org/?p=digikam.git&a=commit&h=2901c5564ccbbd6999ab8847c39870005c636fc4
Comment 6 Veaceslav Munteanu 2014-03-09 15:42:25 UTC
Also, it's only me, or write tags do not purge old tags from images?
Comment 7 Michal Sylwester 2014-03-10 03:52:40 UTC
I think there are several use cases that behave differently...
I think IPTC handling was written to not touch unknown tags (don't remove all tags, just those being changed). However in my experience with XMP the old tags are removed (this is empirical, not from code...).

There are some strange scenarios where synchronization of metadata is not behaving the way I would expect, but tags in my files are quite a mess, so I haven't reported them as I think sometimes this could be the reason... Also I'm not 100% sure how some operations are supposed to work.

Normally I keep metadata in sync with db. Normal tagging is straightforward, I add a tag, click apply, it's metadata is updated.
2 examples where it's not read/written:
1. When file is tagged outside digikam, it seems to detect the change (file seems to be reloaded), but tags are not updated until manually running "reread metadata..."
2. When tag is deleted (right click on tag, "delete tag"), it's gone from digikam but metadata is only written after manually triggering "write metadata" (my workaround: first manually remove the tag from all images - this will update the metadata, and only then really delete the tag itself)
Comment 8 Veaceslav Munteanu 2014-09-02 10:36:27 UTC
This one has be FIXED. Other tags related problems are being discussed here:

https://bugs.kde.org/show_bug.cgi?id=337688