-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop the collective-idea for something else, like users+groups #585
Comments
I think it is quite likely that a user no longer knows in which group a document he is looking for is located. I understand that the backend should be cleanly separated. (Where documents are stored, that a search query goes only to one group, etc.). But I don't think this clear separation would be necessary in the frontend, or? So when a user makes a search query, N search queries (to all groups) could be made and the results combined. (Unless he explicitly chooses a filter). One could then define colors / symbols / labels for each group that clearly separate the results. The option to move documents between groups should also be possible, I think. |
Ah ok, I see what you mean. I like it! I think this is possible even with one query. The query can by default be restricted to all groups where the current user is member. I admit I have a kind of love-hate relationship with the collective idea. Sometimes I think it's great, sometimes I think it's stupid :-). An example, where I like it: I have a collective for my family containing all the postal and e-mails, invoices, contracts, insurance stuff etc. And I have a collective to store some papers I want to read or have read. This is not private stuff, but I like to have it separated. When I pay invoices I don't want to see these papers and when I want to browse through the papers I don't want to be bothered by invoices and all the annoying things I have to do tomorrow etc. I think, if users create many groups and forget where they store things, they should probably think about their organization/workflows? A software may not be of much help then? But I totally see use cases where this would be great, like for groups where members are part of different "departments" etc. I myself probably don't have a use for this, but maybe this will come some day :-) Maybe both is possible. When using groups, one could switch the context to a single group or set it to "all". Via a user setting, one could set his/her preferred context after login. |
Hi eikek, |
Hi @marcogiorgio , thank you! The state is that I still like the idea, but don't expect anything in the near future. I simply don't know when or if I go for this - the effort is quite high. The collective concept was an idea more for strictly separated accounts (that are not used by the same person). In most cases only one collective is needed I think. But I would also now rather like the group concept from this issue :) |
I justed wanted to leave my 2 cents on this: The collective feature is one of the primary reasons for a switch from Mayan to Docspell for me. I love the idea behind it to seperate multiple namespaces (for example for multiple business) in one instance. Before, I had a Mayan setup for my private documents and one for my business. Administrative effort was too much in the end. With Docspell I can easily seperate internal business, external business / clients, and private stuff in one setup. This might not be for all, but for me it's just perfect. Please do not drop this feature ;-) |
Hi @taenzerme - yes this feature will not be lost, I also like it 😄 It will change only in that users would be defined independently and not "below" a collective. So you can't have two same usernames anymore that belong to different collectives. But you can still create collectives that will be separate spaces for documents. Then users can be associated to them (so far the idea at least). That means that docspell can know all the collectives a user belongs to and it would make it possible to switch collectives via a click in the ui, removing the need to do a re-login. |
Files may also belong to more than one group. One example is the passport scan, which I obviously want in my family group, but I also need for KYC for each and every business I'm involved with. |
Not sure if I understand correctly here. The plan is to always have strictly separated spaces for documents, but then allow to query them as a whole (or just a single one of course). To associate one documents to multiple groups/colllectives etc is not intended. |
I've come around to agreeing with you that documents shouldn't get shared, especially since the metadata on the documents might very well differ in different contexts. Stupid example, but my passport might be tagged |
That would be the best approach, as it would allow to keep using the collectives, while dropping the need of multiple accounts. It would also fix the issue of having to set a specific collective a user can sign-into when using a OAuth provider. Is there an approximate (or very loose) ETA for this feature @eikek ? |
This is a follow up from two issues #367 and #21.
The collective is thought to provide the following:
But this concept is not very flexible and seems confusing (see #367 , #21). Maybe (probably) there is a better option hat also provides the above features. This issue exists to explore/discuss these.
A possibility is to migrate to user and groups, as suggested by @MarcSN311 in #21). A collective becomes a "group" and a user can be member of multiple groups. On registration a group with the username is generated to have a start. Most things could stay the same (probably). A user would login only with the user name. The group/context can be switched without re-login. Documents would be owned by a group as before.
The text was updated successfully, but these errors were encountered: