Bug 375656 - Tags view (left side) includes grouped images when it shouldn't
Summary: Tags view (left side) includes grouped images when it shouldn't
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Albums-ItemsGroup (other bugs)
Version First Reported In: 5.6.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-28 13:30 UTC by Jens
Modified: 2025-12-18 07:25 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 8.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens 2017-01-28 13:30:45 UTC
If I tag an image which has images grouped underneath it (which do not have the same tag) I would not expect these images to show when filtering by tag using the left side tags view.

But they do.

I would only expect images to be shown that all have this tag applied.

Example: 
- Create album with five images 1..5.
- Tag image#1 with "Foobar" tag and drag images 2..5 on image#1 (to group them).
- Go to tag "Foobar" in the left sidebar.
- Image#1 is shown with a "grouped images" icon. This icon can be clicked to reveal images 2..5, which do not have this tag.

I would expect the "grouped images" icon only to be visible if there are images grouped beneath image#1 that *also* have the same tag.
Comment 1 Jens 2017-06-18 20:32:41 UTC
This bug is still in the 5.6.0 pre-release but it is stranger.

- Tag some images that are grouped
- Go to the tags view on the left side
- Open the tagged group
- Untag the images *inside* the group
  -> they disappear from the tags view, which is correct
- Close the group
- Open the group again
  -> Images inside the group reappear, even if not tagged - this is incorrect

I would expect only tagged images in the tags view, regardless of grouping status - see previous comment.
Comment 2 caulier.gilles 2020-08-02 12:56:11 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 3 caulier.gilles 2023-04-21 14:41:22 UTC
@Jens

digiKam 8.0.0 is released. This file still valid ?

Gilles Caulier
Comment 4 caulier.gilles 2023-10-12 05:57:18 UTC
Jens,

What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?

https://files.kde.org/digikam/

Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110.

Thanks in advance

Gilles Caulier
Comment 5 caulier.gilles 2025-04-12 06:59:41 UTC
Jens, any feedback here ?
Comment 6 caulier.gilles 2025-12-18 06:58:19 UTC
Maik,

Have you tried to reproduce the context described on original post ? Here i tried, and i cannot reproduce the dysfunction.

Gilles
Comment 7 Maik Qualmann 2025-12-18 07:08:14 UTC
Well, that's the old problem: some users want to see groups in search results, and others don't.

Recently, we've started displaying all groups as "open" in the Search, Similarity, and People tabs. This is because we received numerous bug reports that search results in closed groups weren't being displayed.

We can also display groups as "open" in the Tags tab.

Maik
Comment 8 Maik Qualmann 2025-12-18 07:12:02 UTC
On the other hand, it's a group, so they've decided to group them together.

If the leader is now displayed in the tag search, then I can open the group. I find this behavior normal.

Maik
Comment 9 caulier.gilles 2025-12-18 07:25:32 UTC
1/ This what i expected too. I think the logic is fine here.

2/ Also, the new helper view for groups from the image properties sidebar guide users about open | closed groups. The new icon view group visibility introduced recently must help to handle grouped images in this use case.

I close this file now.