Bug 448223 - Warning ("Another tag with the same name already exists") when merging several tags appears too soon
Summary: Warning ("Another tag with the same name already exists") when merging severa...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Keywords (show other bugs)
Version: 7.4.0
Platform: Flatpak Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-10 17:39 UTC by MarcP
Modified: 2023-05-01 20:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.1.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2022-01-10 17:39:09 UTC
SUMMARY
If you drag and drop a tag to another place of the tree where another tag is called the same way, you will be asked if you want to merge them. However, in digikam is not possible to move elements from one place of the tag tree to another if there is another operation pending.

So, if you drag two or more tags, you will first be asked if you want to merge the first of them ("Another tag with the same name already exists. Do you want to merge the tags?"), and immediately after answering Yes, the same popup will appear for the second one. Answering yes to that one however will show a warning message and cancel the whole operation. 

In order to merge two or more tags you have to accept the first merge and wait until the progress bar reached 100% to click again on Yes on the popup window. And repeat that operation for as many tags you are merging. Clicking yes too soon will cancel the process and the tags will not be written (potentially desyncing the database and the picture metadata).

I think digikam should wait until the previous operation has finished before showing the popup again, so no errors are caused if a user clicks "Yes" too soon. Also, it could show the name of the tag to be merged in the same dialog.

STEPS TO REPRODUCE
1. Drag and drop two tags and merge them with other tags.
2. A first confirmation popup will appear ("Another tag with the same name..."). Click on Yes.
3. Immediately, a second confirmation popup will appear. Click on Yes.

OBSERVED RESULT
A warning message appears saying that the operation could not be completed and the process is cancelled.

EXPECTED RESULT
Either do not show the second popup until digikam is ready to merge the second tag, or queue the process so it doesn't ask for confirmation every time.

SOFTWARE/OS VERSIONS
Digikam 7.5 (flatpak) 
Build date: 23/12/21 10:27 (target: Debug)
Rev.: 6c73e98ec8403ac5c94e289b511d8ac258a95be3
on Ubuntu 20.04 LTS
Comment 1 Maik Qualmann 2022-01-10 18:04:45 UTC
The already running merge process will not be canceled. Only the new merge process that caused the dialog is not carried out. We would only have the option to block the GUI with the warning message and then continue when the current merge is finished. A kind of waiting buffer is not really feasible because the tag tree changes due to the ongoing processes.

Maik
Comment 2 MarcP 2022-01-10 18:11:15 UTC
Would it be possible to check if all the merges in a batch are non-conflicting (e.g. a future merge is referencing to a tag that has been deleted or merged in a previous merge), and only show one confirmation popup for all?
Comment 3 Maik Qualmann 2022-01-10 18:56:13 UTC
The problem is not the merging of the tags in the database, this even takes place immediately and in the GUI thread and does not take any time. I remember that we introduced the warning dialog on the basis of a bug report from you, because you had other metadata writing processes running and then changed the tag tree, which leads to inconsenting image metadata. The warning dialog appears if a process is being executed in the Progress Manager at all, this could also be a copying process.

Maik
Comment 4 MarcP 2022-01-10 19:06:12 UTC
Mmm, I don't remember the exact context now, but I believe consistency in the database/metadata should be more important than user friendliness. 

In any case, the thing is that the user should not click on the next "Yes" until the changes on the previous picture have been applied, because the following file won't be processed then (and 99.9% of the times the user would want the changes to be applied). What could be a good strategy? Couldn't that popup be delayed until it's the next picture's turn somehow?
Comment 5 Maik Qualmann 2022-01-10 19:14:26 UTC
Ok, it wasn't a bug report from you. ((:-)) Bug 406309

Maik
Comment 6 MarcP 2022-01-10 19:16:59 UTC
No worries, it sounds like the kind of thing I would complain about : )
Comment 7 Maik Qualmann 2022-01-10 19:19:28 UTC
We are in the GUI thread with drag & drop. If we delayed it, nothing would happen during the drop, no message, no change in the tag tree ... nothing that would be particularly problematic. If we wait, we would block the GUI and nothing would be selectable anymore.

Maik
Comment 8 caulier.gilles 2023-05-01 16:32:40 UTC
Maik,

What the status of this file exactly ?

Gilles
Comment 9 Maik Qualmann 2023-05-01 20:20:14 UTC
Git commit bb5873182d190f592773d9f49eb6d99881a56307 by Maik Qualmann.
Committed on 01/05/2023 at 20:19.
Pushed by mqualmann into branch 'master'.

remove progressmanager warning, since we are now cascading jobs
FIXED-IN: 8.1.0

M  +1    -1    NEWS
M  +0    -14   core/libs/album/manager/albummanager_talbum.cpp

https://invent.kde.org/graphics/digikam/commit/bb5873182d190f592773d9f49eb6d99881a56307