Multi-User options

[totti4ever]

Hey, I was wondering whether there was an idea how to cope with the situation of multiple users (i.e. wife and me) with common documents plus those which are not of interest for the other one (does not necessarily mean a physical protection)

Would tags plus user defined dashboards be the answer? Would that be possible already today?

Cheers

So I set ng up and had a look. I found groups and users, but can't really do anything besides allowing admin access for users. Plus changelog says they should have been removed in 0.4?

[jonaswinkler]

Simple solution: have a tag for both of you that marks documents private for you. We'd need an additional filter ("Does not have tag X"), so each of you could save a filter that does not show these documents. However, that's not ideal.

We could investigate limiting the documents users get to see based on the metadata they have. For example, you could define a rule so that your wife does not get to see whatever is tagged with "private".

However, I don't have a need for that, so we have to get some more input on what's actually needed and figure out a solution that's versatile enough to meet the needs of everyone.

I've enabled user management simply so that you can change your password. It's not integrated with anything as of now.

[totti4ever]

What is great is that you can already add different users and they can have their own views! Guess this might already be enough for me right now.

Maybe a quick win could be to enable admins to attach a default filter to a user like tag not contains xx. This is kind of similar to Jira's boards. If that somehow plays together with the normal searches and so on (additive) this could be nice?!

[jonaswinkler]

Before jumping onto anything I'd like to see if django's built-in permission and authorization system can be extended to fit our needs.

[Exordian]

I'd also be interested in such a feature as well as i'd be fine with the simple solution to filter specific tags (default search filter) for other users.

btw thanks for your work on paperless-ng !

/e: found a related PR: the-paperless-project/paperless#548
a collection field would also better i guess. i'm thinking of collections like 'mine', 'wife', 'kid1', 'household'.
collections and permissions are managed by the admin. users can be assigned read permissions for specific collections.
new documents without any collection can be claimed by any user from an inbox (or by automatic rules)

[jonaswinkler]

Hello, and thanks for your interest in the project and your suggestions!

--> I'm not feeling too excited about adding new entity types to paperless, if it's not absolutely necessary. That doesn't mean that I wont implement this, I'm just trying to work with what we already have and go for simple, yet versatile solutions.

The ideas in the PR don't look to promising. A document can belong to multiple users.

Right now, I'm thinking about something like this:

• Ability to define inclusive / exclusive rules based on metadata in the admin. Think about: define a set of tags/correspondents/document types for a user and then have a switch that selects whether that user has access only to documents with selected metadata (inclusive), or to all documents except those with the selected metadata (exclusive).

• This comes with its fair share of implications.

  1. The user can only see documents when everything matches. When a users is allowed to see the correspondent, but not a specific tag of a document, it is not shown.
  2. The user can only assign metadata for which access is configured.
  3. With inclusive rules: When the user creates new metadata, the users must automatically gain access to that metadata as well.
  4. When creating metadata: If the user chooses a name that already exists but is inaccessible to them, they'll get a weird error message. With multi user systems, There should be no way to figure out what other data exists in the system.

--> You see, this isn't all that easy. Honestly, I am wondering if it's really necessary to have a system that enforces this kind of stuff. You could just use saved views.

[geomule]

I have the exact same use scenario.

[jeremymeyers]

Also if two people are both adding their own financial stuff and dont want to get them mixed up for ease of visibility, regardless of privacy concerns.

[mirisbowring]

@jonaswinkler i think there could be a more simple solution:
As some people already mentioned:
each user get's a separate sub-importfolder:

Import
- Alice
- Bob
- Mallory

A mapping table is needed.
If Doc1001 is uploaded to Alice, it get's processed and mapped to alice by ID
By default, Alice can only see documents, she belongs to.

Now she can share some documents to a specific group (with one or more users in it).
An additional feature would be to differ between read and write access (default Rwad-only).

At the end of next week I have some time left and could do a pull request with this feature if you think this would be a good addition.

[jonaswinkler]

@mirisbowring Alright. Some notes.

• Mapping table: Needs some easy confguration. Not sure yet how to do that. I think JSON strings in configuration variables are rather ugly.

  • Maybe something like PAPERLESS_CONSUMPTION_DIR=/path/to/consume/{user}/, and the consumer detects that.

• Scanning multiple folders: Everything should be in management_document_consumer.py. Two options come to mind:

  • Start a thread for each user. This might be the most compatible approach.
  • Try to guess the user within the current logic.
  • Keep in mind that there are already features in place that deal with sub folders and make tags for them. Don't break that.
  • Also consider what happens for users that don't configure a "mapping table" - Should we simply not set the owner on a document at all?

• Passing the guessed user to the task queue:

  • Scanning the consumption folder and actually consuming documents are done on different processes. Django-q is used as the task processing queue, and you need to pass the user (if any) to that as well. Have a look at how titles / tags / correspondents are passed to that, namely all the override_* arguments. passing the user will work in the same way.

• Database model migrations:

  • Please try to make your changes non-intrusive for current users. You'll need a plan for what owner to set on existing documents.
  • Many users use watchtower and don't even notice that their instance got updated. Manual intervention in database migrations is an absolute no go.

• Front end changes:

  • Needs some support for sharing documents with groups / users.
  • You'll most likely need to extend the API for that, such as providing a new action /api/documents/<id>/permissions that both returns the current set of permissions on GET and updates them on POST.
  • You most likely don't want users who are not the owner of a document to view/edit permissions.

Testing: I'd like to see tests for

• the API (only return documents you're supposed to see)
• the document_consumer management command (passes the correct user to async_task)
• The consumer (sets the correct user on new documents if asked to do so)
• Generally, just look at the coverage report (generated by pytest) and make sure that all your code is covered. I did that for almost the entire backend by now.
• The front end is not tested at all. Just make sure the buttons work :)
• I can help out with testing, especially since some of the tests are rather complicated (management_document_consumer)

Regarding PRs:

• Make PRs to dev. However, I'd like things on there to be reasonably complete. If you want your changes merged earlier (and allow me to work on that as well), make a PR to feature-multiuser, branched from current dev.
• I'd opt for the latter, since this is a rather large package.

[jeremymeyers]

From a UX perspective I would think that documents uploaded to paperless should be assumed to be owned by the user who has uploaded. You would also need a "make available to all users" option during the consumption process. Or rather perhaps "Make only available to me" so current users workflows aren't broken.

[d8sychain]

Also the idea of hiding certain documents from different employees. Upload all documents, bank statements, financial reports, invoices, receipts, and giving certain employees only access to certain document types depending on their position within the company. I don't personally have such a use case, but I can see examples of its uses.

[tesmerjg]

I too am interested in the multi-user options, but from the perspective that I'd like to have users that are unable to modify or create document-types, tags, or correspondents, but rather simply add and remove existing ones from the documents. I think I saw a recent bug where this was determined to be a big deal. How can I help?

[CrystalMethod]

I am also interested in the "multi-user" feature. For me it would sufficient to add appropriate user labels to the documents.

However, it would help a lot to automatically apply these labels of the various users. I scan documents to a network share and can set up different locations per person. Now it would be nice to be able to apply labels per source location automatically as well.

[Spoker]

I believe you can already do that with "PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS="
see: https://paperless-ng.readthedocs.io/en/latest/configuration.html#paths-and-folders

[marcogiorgio]

Hi, I use this app with my girlfriend and this feature would be really useful. I currently use tags/views to logically divide the docs, but I think that a "physical" separation implemented as a permission system would be a preferable and much cleaner solution . Thanks for your work

[swissbyte]

I have the exact same situation. I would also be happy to donate some money for getting this feature implemented :)

[kbabioch]

Same for me. I would also like to host this in a family context, but everyone should be in control over his own documents and decide by himself what documents can be shared with all, and which ones cannot.

The basic functionality is really great and robust, but without multi-user support, a lot of use cases are not covered with this project.

[mtettke123]

would spend something, too

[kbabioch]

What is the best way to help with such a feature? Are there already any specific plans / ideas on how multi-user support should look like? I think working out the concept first, is essetnial here, in order to have a vision on what needs to be developed, etc.

[mirisbowring]

The ASN must be global.
Is doc x from User A has Id 1 and he shares it with User B but B has already 2 documents, either they would have 2 different ASN (not good), a newly assigned ASN (horrible) or a duplicate.

With a global ASN you would "loose" a ASN series, but that should not matter. User A (1,3,4,5,8,...) User B (2,6,7,9...)

One could make a ASN per User and append the username, but then i would need to also write this down.

So a global would be much more easy to handle (for the user and the development)

[totti4ever]

I completely disagree. If users scan and import their docs themselves they wouldn't be able to actually stamp a sequenced number on their scanned papers as they wouldn't know how many documents have been added by others in the meantime. Would they?

Nevertheless, this could be a configurable option as it should be known and constant per installation

[marcogiorgio]

@jonaswinkler may I ask if there are any chances you will implement this feature request? From your post it seems that in your opinion this feature isn't necessary after all. If this is the case, we are discussing for nothing I guess...
Thanks

[mirisbowring]

I completely disagree. If users scan and import their docs themselves they wouldn't be able to actually stamp a sequenced number on their scanned papers as they wouldn't know how many documents have been added by others in the meantime. Would they?

Nevertheless, this could be a configurable option as it should be known and constant per installation

But the ASN in Paperless is generated AFTER the scan...
So i scan my Doc, enter Paperless, press ASN+1 and write that number on my Doc to archive it somewhere.

[totti4ever]

That would mean, you cannot batch scan multiple docs without looking into Paperless inbetween.

[HammyHavoc]

Interested in Paperless, but this is somewhat of a showstopper as-is as not everybody will have signed a specific NDA etc., but those documents still need handling within the workflow.

[steinerlein]

Hi,
although it seems that this feature is not super high I would like to add my support for this. I think it is an important set of features for the private use of paperless-ng.
While I don't need the permission- or tag-based access control, I would like to keep the physical documents in separate binders (for each person). The workflow I would like to realize is to have ASNs with a prefix (A001, A002, B001, B002, B003, ...)

Thanks for your work so far, this project is great as it is already!
I think you should set up a way for users to contribute financially as to enable you to spend more time on this 🥇

Keep it up!

[mirisbowring]

In this case it would be better, to append the Identifier instead of prepending.

so you could keep the current "1"+A, ... "243"+B, ... , "1366"+A, ...

And we would need to make sure, that the Identifier is unique. Imagine Person A shares something with Person A2 (same Name).

It would be confusing if a "Max" has an C as identifier.

[steinerlein]

I will go ahead and solve it like that:
We'll make use of the ASN as it is and use a Tag per phyiscal Binder.

An example:
Anna has 5 documents;
Fred has 3 documents;
They share 2 documents;
There would be ASNs 1 through 10;
There would be two tags: A for Anna, F for Fred;

As the documents came in randomly, the ASN+Tag mix could look like this:
Tag "A", ASN 1
Tag "A", ASN 2
Tag "F", ASN 3
Tag "A", ASN 4
Tag "F", ASN 5
Tag "F", ASN 6
No Tag, ASN 7
Tag "A", ASN 8
Tag "A", ASN 9
No Tag, ASN 10

The physical documents will be marked correspondingly and be sorted into three binders:
Binder for Annas documents: "A1", "A2", "A4", "A8", "A9"
Binder for Freds documents: "F3", "F5", "F6"
Binder for shared documents: "7", "10"

I am happy to get someone's comment on this approach. Am I missing something?

[prometheanfire]

I'm not sure if it's perfect fit or should go into another thread, but correspondents generally has the from, not the to aspect of a document. So far the only option to document the to trait is via tags. It'd be nice if correspondents was multi-selectable so we could list all parties involved in a document.

[prometheanfire]

Just found #1309 after I posted this, which is exactly what I'm after :D

[jacobalberty]

Just gonna throw my two cents in. I'd love to have an option for groups where users can be added to different groups with either read only or read/write perm and documents get added to the group. To me that would be the ideal paperless multi user setup.

[kadrim]

Same here, for me paperless will only be usable if we can specify which users (or groups) can see which documents (or tags)

I already have the consumer configured to process subdirs and apply the tags, but then I would want to add permissions to users/groups for tags which should be "private"

[kadrim]

as it seems this can easily grow into a much larger PR i think it would be best to keep the feature PR as small as possible with as little impact to the main branch. especially since this repo might get forked for all future development, so i want this change to be compatible with that.

also, i think there really is a need for a solution and even if it is not the best, some sort of implementation that has no breaking changes will be an improvement for future development.

the default should be that no tags are automatically added and therefore uploaded documents are visible to anyone by default. If private documents are needed, a rule for adding a tag should be created.

that is exactly what i was thinking about.

there are many more issues that need to be adressed with introducing something like that (i.e. always add a private tag to each new uploaded file by default? what if a file has multiple private-tags, but the current user has only permission for one of the private-tags? does he have to have permission to all those tags? or just one?). i have my personal opinion for most of these questions, but i think it is a valid approach if i start implementing the PR and the discussion moves there, identifying topics that must be addressed in the first iteration or if something can be adressed via a separate issue. keep things atomic :-)

[schoettl]

@mtettke123: The "real reason", I see, is just a practical one: Who would contribute this great PR and when? Chances to get a smaller change done are maybe better. ^^

[mirisbowring]

The Problem with this approach is the same problem, every big software company has.

Instead of thinking about the solution and concept before, they start throwing in small solutions to make at least any progress. But the more "small progress" Features get added to fix a much bigger problem, the more complex it will be in future. In germany we say "historisch gewachsen".

If the breaking change would be too large, we as the community should consider a Fork to Paperless-NG2 or something.

Since this feature has been requested for more then several years, many requirements have been specified.

So before implementing anything, there should be an technical concept that respects all / most of the requirements. Probably adding user stories are supporting the understanding of some requirements.

And i totally agree with @mtettke123....
If a "visible by default" multi user option is going to be implemented, this software is unusable for me and many others. In this case, i could just host multiple instances of paperless hand have much less trouble with managing the documents instead of checking wether a sensitive document has been exposed somewhere because i forgot to set a "private" tag.

[kadrim]

i totally get, what you are saying. and if this project was run by a company (or backed by one) i would totally agree.

in germany we are also quite good at overengineering ;-)

the problem with oss-projects is also quite often: good concepts, many ideas, hard to realize, no implementation - that leads to a low adoption-rate. Like paperless-ng could be quite good, it could be used in companies, but in reality it can't be, due to missing key-features. Implementing those could provide some form of sponsoring, insight etc.

I am not saying, that every PR should just be done and later fixed, but in this case i think this is the only valid way for me to stay interested at all in this project. Because without a solution i will simply have to jump ships.

I agree, a fork would be best, with a new setup and multiple persons in charge. If that time comes, it will be great, until then, i need to find a way for me to cope with the situation, and implementing this feature in a way that it stays compatible to the next steps in the progress of this project seems valid. Well, and on the other hand, my PR will probably not get merged anyways, so it's just my time that is wasted :-D

If a "visible by default" multi user option is going to be implemented, this software is unusable for me and many others. In this case, i could just host multiple instances of paperless hand have much less trouble with managing the documents instead of checking wether a sensitive document has been exposed somewhere because i forgot to set a "private" tag.

i quite can't follow you on this. what you are describing is the status-quo, because currently everything is public. So you would also right now have to run multiple instances with no way to share "some" documents whatsoever.

Or did i get something wrong here?

[mirisbowring]

i quite can't follow you on this. what you are describing is the status-quo, because currently everything is public. So you would also right now have to run multiple instances with no way to share "some" documents whatsoever.

My Problem would be to know, that the "real" multi-user will never come.

Currently I am running multiple instances, but that is pain in the ass when it comes to sharing specific documents (parents, wife, parents of wife, grandparents, etc.)

[Strohhut1]

Multi-user support would be great!

My Idea:
Use different Folders for each user, named after the user.
Whenever someone is logging in, only the files in his folder will be displayed.
Plus an option to allow users to include other folders to share files or have a "family" account. (use existing groups option)

If I have time I will try and implement something like that.

[mirisbowring]

In my Opinion, a tag based system (all documents in sam folder) is much more appropriate.
I you share Doc A with Person X, Person Y and Group Z, it would need to be in three different places.

Also, the most "difficult" part is to handle the mix between personal DocID and shared DocIDs

[Strohhut1]

Hmm agreed, permissioned tags would be easier to realize.

My Idea is more of a "physical" separation, that would also be useful to easily backup and restore ... but maybe that is a bit too much 😅

[mirisbowring]

In case of Backups, you should also Backup the Database. Probably we could create a Backup and restore script.

[mtettke123]

In my opinion, the option to set items read only should also be considered. So there should be the classical none/read only/read write concept based on ... tags?

Maybe the easiest (and safest) solution could be that every users sees only his own files, unless there is a tag added, that has ro/rw permissions for other users/groups.

[HammyHavoc]

How would you determine the owner of a document? There are many ways to add a document (consume folder, IMAP, REST, script(?)). I think adding a concept of ownership would add a new layer of complexity. Not sure about the aim of paperless-ng but my impression was that @jonaswinkler was hesitating to add much complexity.

By who uploaded it. Ownership can be transferred, or owned by users of x role, e.g. regional manager.

[schoettl]

How to determine who uploaded it when uploaded via consume folder or IMAP?

[mtettke123]

Thats not that easy, agreed.

• Web upload: no problem
• Email: a user could be defined in the setup, should be seemless
• consume folder: a way could be to configure the ownership via rules. maybe subfolders for each user?

But, I agree, these are things that should be clarified first.

[mtettke123]

addition to the above for Email: just add another Email-Accounts. This is already possible. So Email-Account - user. No Problem.

[schoettl]

Regarding e-mail, in our company, it would also require user groups because [email protected] is not 1:1 to a single user.

[physx2494]

Multiple users with rights access will be an excellent addition. After trying all other DMS solutions out there, I can say nothing beats the simplicity and intuitiveness of paaperless-ng

[metalben86]

Hi guys was there any news from Jonas regarding this additional great feature?
Thanks Jonas for this very great software. It will make the life a little easier. :-)

[marcogiorgio]

the project was forked a couple of days ago... I suggest you to follow this discussion: paperless-ngx/paperless-ngx#295

[elnikej]

The multi-user feature would be great.
I used different folders for that use case in other django projects. (created from group_id to have the possibility to match users to the same files if needed)
Is someone working on that ? Some ideas like that were posted before.

[schoettl]

The fork paperless-ngx has quite a lot contributions recently but no PR or issue with "multi" yet.

[LeapingLue]

I'm heading towards a different and easy approach:

I'm currently running two separate paperless containers next to each other on different ports. This allows clean separation of documents while staying easy in maintenance.

Disadvantage: You cannot simply share documents with your partner/ You will have to upload those in both DBs. I'm using a shared consumption folder as well as one for each "User".

[marcogiorgio]

The PR is open so you might want to keep an eye on it. When this will be merged you won't need separate instances anymore: paperless-ngx/paperless-ngx#2147

[LeapingLue]

Good point, thanks!