[Enhancement]: Add metadata type called "flag" #988

New issue

Open

opened 2026-02-20 01:13:17 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 01:13:17 -05:00

Owner

Originally created by @hobesman on GitHub (Feb 23, 2023).

Describe the feature/enhancement

This is intended to function essentially identical to tags, except that it would be something no outside source would modify.
The idea is that "tags" were created for the admin to be able to put a label on something, but that "tag" metadata item has been hijacked for better or for worse by audible tags. Those are good and I don't want to get rid of them, but I also want something I can add that won't be overwritten and won't be mixed up with data from other metadata sources.

So if I want to flag something as kid friendly, or not kid friendly, or sexually explicit, or gory, or whatever, I can do that without worrying that matching to audible will overwrite or bury those flags. If I'm granting or denying users access to things based on these, I don't want audible metadata getting mixed up in that.

Long story short, everything I can already do with tags, but separated from audible's tags.

While we're at it, these should also be written to the .abs file, and should also have the option to limit a user to (or deny a user access to) specific flags.

Originally created by @hobesman on GitHub (Feb 23, 2023). ### Describe the feature/enhancement This is intended to function essentially identical to tags, except that it would be something no outside source would modify. The idea is that "tags" were created for the admin to be able to put a label on something, but that "tag" metadata item has been hijacked for better or for worse by audible tags. Those are good and I don't want to get rid of them, but I also want something I can add that won't be overwritten and won't be mixed up with data from other metadata sources. So if I want to flag something as kid friendly, or _not_ kid friendly, or sexually explicit, or gory, or whatever, I can do that without worrying that matching to audible will overwrite or bury those flags. If I'm granting or denying users access to things based on these, I don't want audible metadata getting mixed up in that. Long story short, everything I can already do with tags, but separated from audible's tags. While we're at it, these should also be written to the .abs file, and should also have the option to limit a user to (or deny a user access to) specific flags.

deekerman added the

enhancement

label

2026-02-20 01:13:17 -05:00

deekerman commented

2026-02-20 01:13:17 -05:00

Author

Owner

@vincentscode commented on GitHub (Mar 16, 2023):

Do you think this should replace the explicit option?
If implemented this could also be used to implement https://github.com/advplyr/audiobookshelf/issues/1408.

Should this be entirely user-controlled or should there be pre-made flags?

@vincentscode commented on GitHub (Mar 16, 2023): Do you think this should replace the explicit option? If implemented this could also be used to implement https://github.com/advplyr/audiobookshelf/issues/1408. Should this be entirely user-controlled or should there be pre-made flags?

deekerman referenced this issue

2026-02-20 02:02:19 -05:00

[Enhancement]: Advanced search #1516