Bug 459065

Summary:	Inactive bundles may incorrectly hide tags in resource choosers
Product:	[Applications] krita	Reporter:	Lynx3d <lynx.mw+kde>
Component:	Tagging	Assignee:	Krita Bugs <krita-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	griffinvalley
Priority:	NOR
Version First Reported In:	git master (please specify the git hash!)
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Lynx3d 2022-09-13 16:30:53 UTC

SUMMARY

When a tag is linked to a bundle (i.e. has the storage_id of a bundle in the tags_storages table), then deactivating that bundle makes the tag disappear from the list of tags in the filter dropdown of resource choosers, even if it is used outside that bundle too.

An example is the "demo" tag from the "Krita 3 Default Resources" bundle that exists after initializing a fresh resource folder.

STEPS TO REPRODUCE
1. Make sure the "Krita 3 Default Resources" is active, that should make the "demo" tag available for brush presets
2. Tag some preset outside the "Krita 3 Default Resources" with "demo" tag
3. Deactivate "Krita 3 Default Resources" bundle

OBSERVED RESULT
The tag disappears from the tag filter dropdown, as well as the available tags to assign to other presets.
Only the resource tooltip of the preset you just tagged will still show it, but it's inaccessible otherwise.

Since the database can only associate one storage with a tag, it doesn't seem possible to create a folder version from within Krita either.
While you get notified that the tag already exists on the attempt to create it while the bundle is inactive, choosing the overwrite option doesn't seem to do anything.
And using "Save Tags to Folder" in resource manager creates a .tag file, but the tags_storages entry is still set to the bundle, so the problem persists.

ADDITIONAL INFORMATION

Tested with Krita master at 4ec1dd783197f4eda48a3867666483920f210e68

Unsure for how long this problem exists, I noticed some missing default tags a while ago (Ink, Paint, Sketch) with resource folder migrated from Krita 4, but forgot about it again.
Apparently it was only worked around by adding folder storage .tag files for them, but the underlying issue still exists.

Comment 1 wolthera 2023-01-19 12:42:25 UTC

Hey,

I'm very confused, I cannot reproduce with the Krita Version: 5.2.0-prealpha (git 5c98a72) Appimage with Qt 5.15.7.

But at the same time we don't seem to have changed anything there in the past few months... Is this still happening?

Comment 2 Bug Janitor Service 2023-02-03 05:02:30 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 3 Lynx3d 2023-02-17 09:24:55 UTC

Okay I just tested this again with master (31563e9), and this still happens.

The issue gets hidden if you had used "Saved Tags to Folder" function in "Manage Resources" and then let Krita create a fresh cache by removing resourcecache.sqlite, so make sure to start with a fresh resource folder (or at least a fresh resourcecache.sqlite after making sure to remove all "demo.tag" files in subfolders, which don't exist by default).
After that, the "demo" tag still disappears from the tag dropdowns when disabling  "Krita 3 Default Resources" bundle, even when the tag is used outside the bundle too.

Comment 4 Bug Janitor Service 2023-02-18 03:48:11 UTC

Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.