Nested Folders & Tags

[Lugoues]

It would help greatly in organizing if it were possible to nest folders and tags.

Awesome Project btw!

[totti4ever]

Hey, out of curiosity:
What would be your setup then?

I've been thinking about this a couple of times, but most of the time came to the conclusion that it is something, I'd like to have have because it feels like it should be there.

But then again, having tags and their categories (which actually is a 2-level hierarchy which is also available as filter - even more prominent if setting filters would affect the remaining/shown filters) plus correspondents, plus equipment, plus concerned persons, plus folders... I usually come to the conclusion that all these things together already provide more complexity than I need and more than I would want to use.

Right now I'm rather thinking on how to use the existing vehicles, especially the equipment and certain tags

[eikek]

Thank you @Lugoues for your input and kind words!

I'm afraid this is something I don't want to add right now (I might change my mind later :)). I thought about this at the beginning and found for me personally it adds too much complexity, not only in code but also perceived complexity in the user interface, api etc and I couldn't come up with an 'urgent need' to justify this effort. But I certainly miss many workflows/organization habits. I use myself only a very simple one. I'd be also interested on how you organize things so that this wish comes up? Maybe some of it can be realized differently or with already existing things (@totti4ever mentioned the tag category which can be used as a first level for tags).

[Lugoues]

Nested tags is really what I currently use. It makes it easy to apply multiple tags using only a single one. A leaf tag would automatically resolve in a search for a parent tag. I got used to this workflow from using sismics/docs and thought it would be quite useful with the auto-tagging that docspell brings to the game.

It's obviously a nice-to-have feature that can definitely be worked around.

[totti4ever]

Could you provide an example of a tag-branch with it's nodes? I'm really really interested as I try to think about what makes sense (and still is doable regarding manual tagging) for myself

[Lugoues]

• companies

  • company-a
    • child-company-a
      • product-a
    • child-company-b
  • company-b
    • child-company-d
      • venture-a
    • child-company-e
      • venture-b

• finance

  • invoices
  • pay-stubs
  • taxes

Given those trees one could tag, or have auto tagged, a document for product-a this would automatically relate it to it's company child-company-b and it's parent company company-a as well as tag it as a company. The auto tagger could also tag it with invoice and automatically assign it to finance.

Without hierarchies in the current system you'd get an auto-tag of product-a but then have to manually go in and add three more tags. This is ripe for human error and incomplete tagging. Hierarchies would also give you the ability to find all invoices for company-b's child companies without having to specify each child company in your search.

Granted some level of this can be done with categories but it's not as flexible.

[eikek]

Hi @Lugoues , I'm sorry for the late reply; I thought I responded back then. I just clicked into the ticket to re-read your text….

I can see that this is quite useful, thanks for the explanation. I could imagine to have nested tags as a generalization to the tag category, so only for organizing the tags themselves. Or would you want to tag items with intermediate tags, like "child-company-a"?

[vakilando]

Hi there and happy new year!
First: thank your for the great software!
I've tested several software (all docker) and ended up with the question wich one to use: Mayan EDMS or Teedy/Sismics or docspell.
I like docspell because of the support of many file types out of the box, the possibility to create tags, concerning persons and correspondents while classifying a document, the address book feature and the fact of beeing non-destructive to uploaded documents.
But I really, really like and use the nested tags in teedy and the file cabinets in mayan!

So here is one more vote for "nested tags" like "sismics/docs" has it - for the same reason as @Lugoues explained.
@eikek , you asked @Lugoues if he wants to tag items with intermediate tags, like "child-company-a". My answer would be "yes".
Another thing: I also like very much the "file cabinet" approach in Mayan EDMS. These are nested folders that depict file cabinets, binders, and folders like everyone of us has to store all the papers (contracts, bills, recipies, ...). That makes it possible to find a file by a "human readable" folder structure.

[eikek]

Thank you @vakilando for your kind words and your vote. And a happy new year to you, too! :-)

I will look at mayan and teedy to see how these things look there. I'm actually in favor for this (nested tags), the only thing is that I'm afraid to grow docspell into a more complex tool, which I'd like to avoid. I need to see how to maybe unify this feature and #522 – having things associated via 1-n and m-n in general, while still being able to have semantics on some metadata…. It probably takes a while until this arrives, though.

Regarding tagging with intermediate tags: What is the use case here? Say when I can tag something with a leave tag, then all intermediates are assigned implicitly. Why would you want to assign intermediate tags only? I'm sorry if I'm not getting it… the example with the company is ok, but this would be modeled using the correspondents from the address book, no?

Regarding nested folders: I'm not sure I want this (haven't looked at the file cabinet yet, though) I myself could never get warm with folders at all. They are very strict and can be replaced by tags easily. What would you use nested folders for that tags don't solve? I actually wanted to get away from the "human readable folder structure", because I found in the past that it doesn't work very well especially in a group of people. Also, I don't really want to organize it myself. The idea is more to find properties to documents (hopefully automatically) and be able to find them back later without having to create some "arbitrary" structure. Most of the time you know something of the document you are looking for (my observation, so I'm grateful for any other insights). Of course this is not 100% , that is why there are tags and custom fields to add other information (e.g. states like "todo", "paid at" etc).

One next thing on my list is a simple query language. Then you can have "bookmarks" and combine those etc. This lets you create something like "virtual folders" for example or many other interesting things. Instead of creating rules to sort something in a fixed folder structure, a query selects all documents you want to have in a certain "folder" or category. As soon as you have confirmed and added metadata, a new document is automatically available in all corresponding queries. Users can have different views on a set of documents. So currently nested folders are not something I plan to add.

[vakilando]

Hello @eikek,
I definitely prefer nested tags (like Teedy has) more than folders.
I do not want to have both - that would be too much and get things to complicated!

Folders:
IF nested folders then they should be independent from tags.
Really only to have the "old school" cabinet structure.
I think it should be the easiest to implement because it's independent from tagging.

Tags:
When you say intermediate tags, you mean tags somewhere in the "nested structure" (not first, not last)?
My understanding: When tagging a document with an intermediate tag it should be auto-tagged with the parent tags.
Like this:

• companies

  • company-a (document-1)
    • child-company-a
      • product-a
      • product-b (document-2)

• finance

  • invoices (document-1)
  • contracts (document-2)

document-1 should have the tags: companies, company-a, finance, invoices
document-2 should have the tags: companies, company-a, child-company-a, product-b, finance, contracts
The bold ones are manually tagged, the italic ones auto-tagged

Your idea with simple query language and bookmarks really sounds exciting!
I'm always open to new ideas - also to get rid of "old school cabinet structure" ;-)

[eikek]

Thank you very much, @vakilando ! Yes, I meant with "intermediate" tags almost what you described - all except the "leaves". I first had the idea to provide a tree structure where the leaves are the tags. This makes the structure independent from the actual tags, but wouldn't allow to assign intermediate tags. However, searching for documents by "intermediate" tags would be possible. Basically it is an extension to the "tag category" making it an index in the tag set. In your example, a user could only tag with "invoices" or "product-a", but searching could be done by "child-company-a" or "finance". I guess this is not what you mean/want. It wouldn't offer anything better (you could organize tags differently per user, but who needs that :-)) and is the same effort as adding a parent-link to a tag :-).

I would then simply add a parent-link to a tag and keep restricting tags to be unique – so the tag is still identified by its name only and not the path (its name + all parent names).

Good you also don't want nested folders and tags :) I also think that this doesn't add much value.

Regarding the "old cabinet structure" – hope it didn't sound derogatory. It's just something I observed for myself … when adding documents (which in my case is far more often than looking for one), I don't want to think about where to put it. For me, these systems (like johnny decimal) tend to become difficult over time (even more with multiple people), but I might be just too stupid for these! There are other people much better in organizing and thus have value in these. So the idea was to only add metadata that is really obvious, maybe even automatically, and get everything else from there. This is the experiment :-)

[vakilando]

A tree structure where the leaves are the tags and searching can be done by intermediate tags is also an idea and should be ok in most cases. On the other hand tagging documents with intermediate tags gives a bit more possibilities.

When you have a clickable tree structure (maybe even with expand/collapse function) you could find the document-x that is about member1, insurance1 and concerns work in general.
You'll find the document by clicking on one of those tags: family, member1, work, insurances, insurance1.
The deeper you click in the tree structure the less matching documents will be shown.
(the example tags are not very good, i know, because they represent existing attribute like concerned, correspondent....)

• family
  • member1 (tagged: document-x)
  • member2
• work (tagged: document-x)
  • workplace1
  • worplace2
• insurances
  • insurance1 (tagged: document-x)
  • insurance2

[vakilando]

Regarding the "old cabinet structure" – hope it didn't sound derogatory. It's just something I observed for myself … when adding documents (which in my case is far more often than looking for one), I don't want to think about where to put it.

No, you do not sound derogatory!
Yes, you are probably right!

[Hoddl666]

Folders with subfolders would be perfect to bring even more order into the documents.

[eikek]

Hi @Hoddl666 thanks for your input. I can see the idea of nested folders. However, just to not have false expectations: currently it's very unlikely that this is going to be implemented. I'm still thinking about nested tags, but folders are out of scope. I think tags are more powerful and can replace folders easily.