[Feature Request] New Custom Field Type Enum

[seijikun]

Hey! Thank you very much for docspell, it's an awesome piece of software!

I was thinking that it would be awesome if there was a Custom field Type Enumeration, which acts basically like Text but only allows a limited set of values/variants.

One use-case I am thinking about for this is tagging documents as: "relevant for tax ".
That way, I don't have to create a new Tag for each year (Tax 2019, Tax 2020, Tax 2021) which would clutter the Tag collection the long run, but could instead have a Tax enum metadata field, with the variants (2019, 2020, 2021, ...).

Another use-case I could think about is: When storing bank account statements ("Kontoauszug") in docspell. One could add a metadata field "Bank Account", with the account numbers as variants - since each statement relates to one specific bank account.

When changing the set of allowed variants, a validation would have to be run against the custom field's instances, to check that no in-use variant can be removed.

[eikek]

Hi @seijikun thank you for your kind words and your input!

Regarding your use cases, I could imagine other ways of organizing it. For the tax case: there is already a date field. so you could use one tag Tax and then search for tag:tax year:2019 for example. So in general, instead of one field containing two pieces of information, one could use two fields. For the bank account use case: you could use here an "equipment" that is your bank account - I hope it is also detected when the account number is on the documents. It would require the user to add possible values before being able to select it.

There have been some thoughts about something similar in #979 (somewhere in the comments) and #528. I think your proposal is similar to these - I think it goes in the same direction? I think something like this is a good idea. An enum is interesting idea, the user is then required to provide all possible values. But this also requires a bit more clicks when adding a new value/changing values - and as you said maybe even validation. It would be simpler if the field was just like the text field, but the ui would then give a list of existing values. But the user could always just enter a new one. This is more convenient but has no validation etc. But I think it would work well in most cases - wdyt? My current preferred way would be to have the fields more flexible in use, since there are already more strict variants (like correspondent, equipment etc). But I'm not sure yet :).

[seijikun]

@eikek Thanks for your response!

There have been some thoughts about something similar in #979 (somewhere in the comments) and #528. I think your proposal is similar to these - I think it goes in the same direction? I think something like this is a good idea. An enum is interesting idea, the user is then required to provide all possible values. But this also requires a bit more clicks when adding a new value/changing values - and as you said maybe even validation. It would be simpler if the field was just like the text field, but the ui would then give a list of existing values. But the user could always just enter a new one. This is more convenient but has no validation etc. But I think it would work well in most cases - wdyt?

Mh, I think an Enumeration field type is quite different than the document relationships that were discussed in the two issues you linked.
The document relationships feel more like a way to represent "exceptional cases" with a small finite amount of documents:
(With the relationship links I would only link documents that have a temporally short semantic connection. For example

• the invoice from a craftsman, and the corresponding invoice from the DIY store with the material
• Several documents that belong to a consultation appointment at the bank.)

Whereas the Enumeration (or Equipment, and Folders, for that matter) feel more like "bringing a large set of documents under one roof" by a common property:
(My use-case with the bank account would link an ever-growing number of documents together.)

(Please forgive my almost blasphemous draftsmanship ;))
That said, document relationships is also a very interesting feature.

My current preferred way would be to have the fields more flexible in use, since there are already more strict variants (like correspondent, equipment etc). But I'm not sure yet :).

I think the custom fields are an extremely powerful feature of docspell, because you are basically unlimited in their amount and flexibility in general. Like that, I could imagine a custom Enumeration field replacing/emulating the very specific Equipment, Direction(Incoming / Outgoing), or even the correspondence features/notations. And while there is only one equipment field per document, you can have an unlimited amount of custom fields - this leads to a lot of flexibility for custom grouping and notation.

A Text field that suggests already used values is very close in its usability, to Enumerations. I'd already be quite happy with that - because my main concern was consistency (Having typos and stuff). However, I think that with the Custom Fields feature many great things could be implemented, and having an Enumeration type in the long run would be good. For me, custom fields are the most versatile feature in Docspell, because they do not impose any notation (like Equipment) or restrictions on their amount. And I still see a lot of potential left, to be gained (mostly with more supported field types).

I hope that makes sense and not too much detail was lost on the translation barrier.

[seijikun]

I just had the idea, that when creating the Custom Field as Enumeration, and listing all the possible variants - one could add a checkbox that optionally allows not only one variant to be chosen at a time, but to allow multiple, like:

This would make it even more powerful.
What do you think?

[eikek]

Hi @seijikun thanks and no worries about your draftmanship :-)

I think I understand now better, what you want to achieve. I already thought about to remove the equipment and replace it with something more generic or have custom fields of type "person" etc. There is also a request to allow multiple equipments/person to be associated. The thing is, while the ideas are nice, it is a lot of effort. So I'm not sure when or if I can consider this. I'm still thinking about some major refactoring, also wrt #585 - but only time will tell, if it is possible for me to undertake this adventure :)

[seijikun]

There is also a request to allow multiple equipments/person to be associated. The thing is, while the ideas are nice, it is a lot of effort. So I'm not sure when or if I can consider this. I'm still thinking about some major refactoring, also wrt #585 - but only time will tell, if it is possible for me to undertake this adventure :)

Absolutely no worries! Docspell is your project and already quite amazing the way it is! I've already decided to use it for my documents.

As an idea: I think it could turn out to be most sustainable in the long run, if you had the built-in features like correspondences, organizations, equipment, from date, to date, due date, ...etc. based in the background on the same data structure you use for the custom fields.
You could use special reserved identifiers for such built-in features like "DOCSPELL_BUILTIN::person", and "DOCSPELL_BUILTIN::equipment". The GUI for people, equipment and companies could basically remain as it is, but then it would no longer be based on a separate feature, but would just be a somewhat glorified enum variant editor in the background.
And when you want to stop supporting such a specific feature, the migration would look like: Rename DOCSPELL_BUILTIN::person => Person. People that were using the feature then don't loose any data since the field just appears as a custom field.

I don't understand too much about Scala (looks mostly like hiroglyphs to me to be honest 😅), but I could imagine this saving some code for the specific features.

[eikek]

Yeah, this is a good idea and it is exactly where the effort is hidden currently :-). I think if I were to do docspell again, I would choose a more generic approach to "associating meta data". When I designed docspell, I wanted a simple system and choose to model correspondents/equipment etc directly in the database (because "that is enough, nothing more will ever be needed" ;)) Well, it went now a bit further than I thought it would …. Using the current way custom fields are implemented for everything else, would be too inefficient, I think. I think it requires a different data model, which means some effort.