Nested tags or Grouping tags by categories

[littletruckman]

First of all, many thanks to all of you for making this fantastic application back to life

I may have a suggestion but I do not know if it was already suggested or even if this is possible (I am just a poor user, not a developer :-) ).

It would be nice to have the ability to organize tags by categories.
Let's see this like having a kind of tag with the property "is_category" set to true and some other tags referring to this tag.

This could be very usefull to keep tags organized in another way than using a naming convention as I am doing right now,making tags very long....

For instance, having the following tags:
Persons (is_category=true)

• John (related_to=Person)
• Peter (related_to=Person)
• Sylvia (related_to=Person)

Vehicules (is_category=true)

• My Car (related_to=Vehicules)
• My Bike (related_to=Vehicules)
• My Plane (related_to=Person)

Hope this find some echo in the feature requests

BR

[ignoreigor]

Why not use another tag like "Persons" for John, Peter and Sylvia and "Vehicules" for car, bike and plane?!
Or saving a view called "Persons" with tags "J.P.S." as stored search criterias?

[littletruckman]

Thanks, @ignoreigor for your reply.
That's the solution I am using now to organize and improve the search of my documents.
I am now facing the need to have some of my tags organized logically to help the correct document classification by users who don't know about my logic (of course a hierarchical list of suggested tags will also help :-)).

Having an additional tag does not simplify the task :-).

[tim-vogel]

I would also consider this extension to be very helpful.

[Sky-Dragon]

Hi,
I find the suggestion also good, as I also work with Hierarchical Tags and I also created a discussion ( #460 )

I know this function from the different DMS and also like to work with parent-child relationships.

As partly the child tags are used less often, like with taxes, which are only relevant for that one year.
But also so that the tag list in the main overview remains clear, see banks.

My examples for this:
Parents: Insurance
Child: Life
Child: Car
--> Insurance-Life Insurance-Car
or --> Insurance/Life Insurance/Car

Parents: Tax
Child: 2020
Child: 2021

Parents: Bank (in my case 5 banks/brokers + family banks)
Child: 1 account
Child: 2 account
etc.
total 13 accounts from me (+family) = Tags

The other advantage, I can build the same structure as in my physical folder

[fboie]

I believe this would be very useful. My reason is that I like to be able to control how my DMS stores the files. Having the folder structure speak for itself might come handy to my family in case I get hit by a bus and the paperless service stops running.

Therefor I would like to be able to specify the tag level in PAPERLESS_FILENAME_FORMAT
e.g. "{tag_lvl1}/{correspondent}/{created_year}/{tag_lvl2}/{title}"

I am currently misusing correspondent. Examples for my correspondents are "Taxes", "Bank Accounts", "Investments". My PAPERLESS_FILENAME_FORMAT is "{correspondent}/{created_year}/{tag_list}/{title}". (tag_list is of course somewhat ugly in a folder view, but better than nothing)

[zinz-code]

Has anyone used Gmail and their hierarchical tags? I would love to see this implemented in paperless.
This would make paperless much more approachable for people that like a folder structure. While keeping the benefits of tags

[bernarddt]

Exactly. Gmail used to not have this feature and you had to use an add-on to build tag names like "Invoices/Abc" that would create a parent/child hierarchy. Then Gmail realised that so many people used that or wanted that that they built the hierarchy ability into their tags as well. So, you use the hierarchy to structure the tags in a way that allow you to drill down or show them in a tree view and expand collapse the tree nodes. This just helps to browse for documents, and seeing a structure than just searching through the pool and seeing lists of documents.

[baca89]

I believe also this would be useful. The combination of many Tags for one document would so be easier

[martiesim]

While I appreciate the added functionality proposed here, I'd like to add that some benefit could be had with a simple ui change (that could serve as a first step):

Define (or let users specify) a split character like e.g. ":".
Let's look at these Tags:
"insurance:life", "insurance:weather", "insurance:health"

These could be saved like this in the backend, so nothing changes there.
But the frontend could display them as a hierarchy.
E.g. in the edit document dialog the dropdown would show:

- insurance
   - life
   - weather
   - health
- cars
- school
   - highschool
   - univercity

Now if these were collapsed on default, the tags selection would look a lot cleaner, even with a lot of tags.
In the tags dropdown for filtering documents, the "top" entry could even be made useful by allowing users to click it.
If clicked, it auto-selects all tags "below" and sets the filter type from "all" to "any".

This would be a purely cosmetic change in frontend but it would already make using tags a lot cleaner imho.
Also this could be applied not only to tags. Types and correspondents could be cleaned up like this too.

[littletruckman]

Really fan of these ideas :-)

[almereyda]

This is the way how GitLab implements namespaced, grouped labels, but the convention seems to be using double colons ::. Single colons would resemble CURIEs a lot, which does seem like unnecessary ambiguity. CURIEs are even better for #4502.

• Scoped Labels | Labels | GitLab
• CURIE - Wikipedia

Single colons are also used for the names of properties in OpenStreetMap, for example. Maybe it's good to keep them for properties, and to use double colons :: for tags.

[pustekuchen91]

I would like to see the functionality like scoped labels from gitlab too for paperless. I think this would be a great extension.

My use case would be:

• tax declaration::2023
• tax declaration::2024

Keep in mind that just one scoped label can be assigned to a document per scope.

[marcelbrueckner]

Keep in mind that just one scoped label can be assigned to a document per scope.

I have documents that are relevant for multiple tax years, so shouldn't this limitation be left to the user?

[martiesim]

Yeah, that limitation feels a little arbitrary.

The way I explained the whole dms thing and labels to my boyfriend was: Imagine the physical papers could be in several physical folders at once.

I would love to "expand" this analogy to the directories on a computer. Imagine the file could be in several directories at once (let's just pretend symlinks don't exsist, like the non-tech-savy-people do).

[Mannshoch]

May this Ideo could be merged with this #1525 - Every thing is a Tag.

[Bitrider11]

I think it´s a good way to have a Main-Tag with Sub-Tags. When it ticks the Main-Tag also the Sub-Tags are shown.
The advantage is when I take the Tag selection only the Main-Tags are shown. So, the list of tags is not so long.
A very good idea and I think it´s not a great think to implement this.

[FizzyMUC]

Any further thoughts on nested tags, maybe even from @shamoon ?
I believe this could be a very handy feature.. I also like to tag my health insurance documents with "health insurance", but they should also pop up if I only filter for "insurance", which would then be higher in the hierarchy.
Actually, I remember this was very well implemented in Adobe Lightroom, where it was used to tag your pictures.

[madduck]

One way I've seen this implemented is by making tags hierarchical, e.g. insurance::health or insurance/health. Both of these make insurance a tag of its own that includes all the tags underneath it.

[almereyda]

I'm fine with the :: notation, but I also like the / proposal.

We've also seen : above, which for my taste resembles CURIEs too much.

[FizzyMUC]

Let's please push this topic up again. It's the feature I crave most...

[EdMueller]

I'm also interested in hierarchical tags, so pushed this topic again ;-).

[EngiBenchi]

Yes this feature is high on my list as well.
I have many manuals and with over 2200 models the list with labels will become very long.
If I can group them under a brand name it will become manageable.
a hiërarchie, Brand->model->model-year-group is want I to create.

[pustekuchen91]

More than two hierarchies would make this to complex in my opinion. key::value should be enough. You could split this into two labels. brand::model + year

The year could be used in combination with multiple brand::model label.

[EngiBenchi]

Yes maybe I'm making it to complex. I do not have yet wrapped my head fully around it.
It is about car models. And model-year-group is a range and it can be a different range for every model. And every brand has it own solution to make that distinction but basically it is a period in time.
So what think I do is brands in a path a 2000 labels for the models and two sets of labels with a year number. One for the start of the model periode and one for the end.
Or maybe custom fields. I also have the file name as identifier....
Or find a different tool. I love the document scan en preview/show options and user management though. We also have a collection pdfs for motorcycles, e-bikes scooters, trucks, campers and wheelchiars. So suggestions are welcome.

[flemmingss]

I support this, and i think it should be more than two hierarchies. This because people has use-cases for it, people who just need two can use two.

Idk how it works on gmail, but instead of making a complex GUI to create these tag-hierarchies, it can be done with a special-character in the tag field.

If the character is "\", the tag value can be:

Vehicle\Car\Volvo 240 (HK33295) <-Tag "Volvo 240 (HK33295)" inside "Car" inside "Vehicle"
Vehicle\Car\Honda Civic (PP33444) <-Tag "Honda Civic (PP33444)" inside "Car" inside "Vehicle"