Multi user permission support

[marcogiorgio]

Hi,
As stated in the title, I here open the thread for one of the most voted feature requests in paperless-ng which is still in discussion. I think this is a killer feature for many users.

This refers to having access control to documents. The multiple users would have their own set of documents. Currently all documents are visible by all users — the authentication is simply to prevent non-users from accessing it.

The basic feature set would be:

• A user's documents should not be automatically visible to other users.
• A user should be able to give permissions (read/modify/delete) to other users with regards to documents and/or tags.
• A user should be able to mark a document as public (automatically available to everyone to read)

[0xBADEAFFE]

Hi, As stated in the title, I here open the thread for one of the most voted feature requests in paperless-ng which is still in discussion. I think this is a killer feature for many users.

This would be a great feature! As allready mentioned, some implemention ideas are allready discussed in jonaswinkler/paperless-ng#52.

[sense4t]

Hi,

like described by @alexthamm in #252, i would suggest to reflect the access restrictions provided by django in the gui as a first step. Users can be restricted in viewing, adding and deleting items like documents and tags that way.

Anything more, like selective read access to a subset of documents or user specific limitations to changing certain tags would imply many more changes and a rather complex implementation concept.

best regards
Stefan

[metalben86]

Hi,
Was there any official docker container for paperless-ngx from Jonas Winkler? And how should we adopt from paperless-ng to paperless-ngx? Thanks
BR Ben

[shamoon]

Please check the readme for more info about this fork. And https://paperless-ngx.readthedocs.io/en/latest/setup.html#migrating-from-paperless-ng . There’s a little more involved if you’re migrating from linuxserver image

[sense4t]

Hi,

unfortunately, the discussion about a multi user implementation seems not to proceed, so i'd like to kick in.

This feature, though wanted from many, seems to be rather complex in clarifying and there are different aspects being reflected in various discussions.

A basic functionality is already available in the admin panel, provided by django, though settings there are not handled by the current frontend.

A suitable UX-concept is needed to proceed.
Are there any people here willing to work on that ?

Regards
Stefan

[Kaaybi]

I'm willing to work onto this 😊

[AnonJervis]

Let me get this straight as I am a bit confused, right now with the latest version even if we set individual user permissions, every users can still view/edit/delete documents right? I noticed this few days ago when I tried to assign users view-only permission but when I logged into their accounts to test they have full permission over the documents.

[stylersnico]

I just wanted to share my paperless installation with my wife and I discovered this, so I don't know what to do.
I don't get the goal of the multiuser support if everyone is basically admin.

How did you manage to set up permission in the admin? I can't even do that.

[csshenouda]

This is desperately needed!
I've made a little change in the source. It's hacky but works for me and my family members as a workaround until multi user permissions are properly implemented. Thought I'd share, maybe it'll help somebody:

sudo docker exec -it paperless-ngx_webserver_1 /bin/bash
apt update
apt-get install nano
cd documents/
nano views.py

Then find class DocumentViewSet(......)

Change:

def get_queryset(self):
        user = self.request.user
        if not user.is_superuser:
            return Document.objects.filter(tags__name=user.first_name).distinct()
        else:
            return Document.objects.all()

This assumes you have set

PAPERLESS_CONSUMER_RECURSIVE: 1
PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS: 1

and that you've named your subdirs under consume like the first names of your users.

Now every user only sees their documents. Admin can still see all.

[0xBADEAFFE]

This is desperately needed! I've made a little change in the source. It's hacky but works for me and my family members as a workaround until multi user permissions are properly implemented. Thought I'd share, maybe it'll help somebody:

sudo docker exec -it paperless-ngx_webserver_1 /bin/bash
apt update
apt-get install nano
cd documents/
nano views.py

Then find class DocumentViewSet(......)

Change:

def get_queryset(self):
        user = self.request.user
        if not user.is_superuser:
            return Document.objects.filter(tags__name=user.first_name).distinct()
        else:
            return Document.objects.all()

This assumes you have set

PAPERLESS_CONSUMER_RECURSIVE: 1
PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS: 1

and that you've named your subdirs under consume like the first names of your users.

Now every user only sees their documents. Admin can still see all.

Perhaps this can be implemented as an option.

[maxkuhlmay]

Hey, this works for me.

I had to create a tag which was named after the user, which has restricted access. Thanks a lot

[maxkuhlmay]

Suggestion:
You are checking the username with a given tag. Wouldn't it be great, if you set a group and compare the group instead of the first name?
this is much better UX than setting a tag with the first name of the user

[MrAlucardDante]

In the mean time, if you have the resources on your server and if you are running paperless in a docker container, you could spin a container per user, this way each user has it's own paperless, with it's own consume/media/export folders.

If you have a domain name, you could use a subdomain per user, otherwise, just use a different port for each user.

That's not ideal, I agree, but that's still works better than the useless user management currently in place.

The fact that the original thread on Paperless-ng is almost 2 years old tells me that multi user permission might never be a thing at that point, which might be fine for a single user or a home server, but this is just not usable in a professional context.

[askielboe]

Hi, As stated in the title, I here open the thread for one of the most voted feature requests in paperless-ng which is still in discussion. I think this is a killer feature for many users.

Could you please add some context on this topic? The title and description does not provide much information about what you're asking or why. I have no idea what "multi user permission support" means.

[joaomlneto]

From my understanding (at least that's what I'm looking for), this refers to having access control to documents. The multiple users would have their own set of documents. Currently all documents are visible by all users — the authentication is simply to prevent non-users from accessing it.

I guess the basic feature set would be:

• A user's documents should not be automatically visible to other users.
• A user should be able to give permissions (read/modify/delete) to other users with regards to documents and/or tags.
• A user should be able to mark a document as public (automatically available to everyone to read) — special public tag

From an implementation perspective, my guess would be:

• Have a document be owned by a user (by default, the creator).
• Have tags be namescoped. Tags of one user are not the tags of another user. (e.g. user1/tag, user2/tag).
• Have an ACL for each tag/document (e.g. user johndoe can do create/read/modify/delete to documents owned by me with tag Z (or to a specific document)).
• Have the tag public have a special role: all users can read those documents.
• Retrieve documents/tags strictly in accordance with the existing ACLs. (tags.filter(tag => haveAccessTo(tag)) instead of showing everything). A document can be seen by a user if either (a) the user is the owner or (b) there is at least one access-control rule that gives access to that user (searching first in the document ACL, later in the tag ACL - document ACL should override that of the tag? I guess this is a whole new discussion… 😆).
• Check for permissions when modifying/deleting a document

Each could be its own self-contained PR, done separately (except for the last two).

We can expand on this later (e.g. allow documents to change owner), but this would probably cover most of the use-cases.

Disclaimer: I use paperless, but haven't really looked at the codebase. I'm not a proper financial technical advisor.

[marcogiorgio]

Hi,
Basically I meant what @joaomlneto explained pretty well. I updated the OP with his thoughts.
Thanks

[askielboe]

Thanks for clarifying! 👍 Edit: And thanks to @marcogiorgio for updating the description!

[Lithimlin]

An additional nice feature would be ACL based on assigned groups as well as giving permissions based on storage paths

[Limerick-gh]

I'd be already very happy if read-only user could be implemented as first "simple" step. So that these cannot edit and delete. Not knowing if it's really simple to remove these buttons etc.

[axgdcode]

I'm not sure the fastest option is to implement a role management.

Another possibility would be to specify a list of declared Paperless' users on a document or to declare it public (this would generate a public url).

[torwag]

First question would be how strict the user management would be.
I see two scenarios.

1. You really would like to separate (on a very low level) documents up to the point that it is almost impossible for others to access them (e.g. they get encrypted). That would cater user scenarios where many individuals share a paperless-ngx server.
2. There is a certain level of trust among the users, one would like to filter the common set of documents to make it easier for the user to find what he is looking for and not get lost by hundreds or thousands unrelated files.

In that case it would be more of a user filter scenario.

Solution 1 needs extensive and careful restructuring as (AFAIK) there is no ownership control implemented in any way. Sharing would require a complete implementation, which is not there yet.

Solution 2 sounds very appealing to me, as it could be basically realized by tags and extending the tag mechanism.
Creating a user also creates a tag with the user name (ID).
Want to share a document with another user add his tag to the document. Want to hide a document from a user? Add a !tag (not tag) to a document.
Users could be attached to groups which in turn have their own tag.

Adding this to the tag system, paperless needs to be modified to run a permanent filter (which can't be turned of. Basically filtering all documents for a certain user to show only those with the user tag, or group tags (of which the user is a member) explicitly exclude groups and users which are mentioned by a not-tag.

This method seems to be less complex to implement. Albeit it might be not water proof, but I believe it would be good for many usage scenarios.

[joaomlneto]

From what I understood, your first scenario is regarding the security of the application and its deployment/environment. Encryption is definitely important, but is orthogonal to the feature here discussed. You can have encryption without supporting multi-user/permissions, which has its own set of benefits, but from a feature standpoint deals more with the backend/storage and the consequences of data breaches, rather than the user-facing feature of deciding who gets to see which of your documents. Definitely worth of discussion, just in a separate thread (in my opinion).

The second scenario can already be implemented with the tags system if one is disciplined enough: e.g. having a user_torwag/user_joaomlneto tag. Not ideal, but not sure how commonly is this scenario implemented by paperless users (since blind trust in fellow users to do the right thing is probably a bad assumption).

[sense4t]

I would prefer starting with a read-only user concept, as in our daily work a level of trust exists among the few users and only deletion of files by accident shall be prevented.
The only attribute that has to be added would be a read only flag on the user account. The gui simply doesn't show edit controls if the flag was detected.

[axgdcode]

I think that it would be easier in the first place to allow the access of a document in full edition (you just need to check if the user is allowed by the author to access the doc).
Then you can add the "profiles feature" in with we could specify the wrights "read, edit, delete" for example.

[michaelkrieger]

As an extension of this, since it likely uses the same area of implementation, this may be a way to segment documents, correspondents, etc entirely.

Take someone who has:

• Personal
• Operating Company 1
• Holding Company 2
  and may want to use one paperless instance to manage the invoices/documents/etc (to avoid an extra 500MB+ of memory consumption of running another instance). You may want to segment your company's records from your personal records (and not clutter every payable/correspondent you have in the company with your personal receipts).

This could be done by simply having a username for 'me_company1', but I would want all of the settings/correspondents/storage-spaces/etc to all be unique to that login as well.

[shamoon]

Just as an update, we are working on this, but it will come in steps, first 'global' permissions i.e. X user can edit tags, etc then at some point 'object-level' permissions. It is not a small amount of work, thanks for everyone's patience.

[pReya]

Just to be clear: Are you working "only" on user-based permissions? Or will this also mean, different users will have their own set of data/can't see documents from other users?

[Kaaybi]

We're working on two things:

• Global UI permissions (restrict access and creation/edition/deletion for management stuff like tags/document types/etc..)
• Object-level permissions (access/edition/deletion) for documents, we first need to establish how we'll do it because it requires a lot of thinking but you should be able to do some fine-grain permissions for each of your documents (for instance allow read-only acces for every users in your groups, read-write for specific users, etc..)

If by set of data you mean correspondents/tags/document-types/storage-paths well it's no it's not covered here (feel free to open another feature request if needed).
If you only mean documents, then it's what we want to achieve yes. You should be able to make your documents public/private/custom perm by defaut and adjust accesses per document after addition.

[pReya]

Thanks for the clarification. That makes sense, and the latter use case is exactly what I was looking for. Looking forward to it. Thanks for your work!

[GonzagueGB]

We're working on two things:

• Global UI permissions (restrict access and creation/edition/deletion for management stuff like tags/document types/etc..)
• Object-level permissions (access/edition/deletion) for documents, we first need to establish how we'll do it because it requires a lot of thinking but you should be able to do some fine-grain permissions for each of your documents (for instance allow read-only acces for every users in your groups, read-write for specific users, etc..)

Hi, Sorry to jump on this, and a newbie here has we are planning to install Paperless-ngx for our school, but, is there no other way than to go with rbac here? rbac, is extremely powerful, but for the average person that will manage permission if can quickly become a nightmare.

Again, I am coming from the average user perspective, and where, for my example, I want to install this in our school and have people with not tech skills to be able to manager user permissions to access or not files/folder/download and so on.

Thank you for your understanding.

[rob-1981]

I m in to :) i user paperless to handel family archive but is do not espechely want everyone cas access certen files. So the only solution for the moment is to make in instance for each member. It's a bit a mess ...

[GonzagueGB]

I though about having an instance per teams, but it would quickly become a nightmare to maintain for a school or company.

I am also all in for that, but if it is done like Mayan eDMS... Hell no :(

[sense4t]

I couldn't agree more! That's one of the reasons I converted everything to paperless ...

[shamoon]

#2147 🎉

(please provide further comments / feedback on the PR)

[Limerick-gh]

Hi, I have setup a test instance, using the feature-permission image, but I don't have any admin access to it. Tried by env variables to set admin account as well as with createsuperuser. Both accounts have only the permission as normal user without rights and can just see Dashboard and Manage on the left menu. Everything else is blank.
Have I missed something in my setup?

[maxkuhlmay]

I had the same issues. I wasn’t able to see anything in paperless.
i was able to open the admin panel and add permissions to my admin user account again. That worked for me. It seems that some permissions are getting lost.

[shamoon]

Thanks for pointing this out, should be fixed, the issue was that superusers weren't having their permissions (everything) passed to the frontend. Should be fixed, just waiting for the image to build: https://github.com/paperless-ngx/paperless-ngx/actions/runs/3652025596

[cirrusflyer]

Has anything changed with regard to permissions? As I understand it, the Django permissions don't actually work?

[Sievers1999]

I also need the function. We have about 30 departments and, of course, the people from the order acceptance department are not allowed to see the documents of the managing director. So the whole thing is unfortunately a knockout criterion for us, although I am a fan of paperless in my private life.

[rodo2021]

I would be happy if this function is available soon.

[cirrusflyer]

I'm testing the dev version that has correct user rights and it's working great.

[jonaswinkler]

Thanks for your feedback :)

[kramerbenjamin]

Thanks :) I am looking forward to see it in the next version of paperless ngx. Its a fantastic software!

[cirrusflyer]

Do we know when the version will be released with the proper user permission settings?

[cirrusflyer]

Thanks. Do we have a rough timeframe on when the version with user permissions will be released? weeks, months, a year?

[Ben-Bitdiddle-DE]

Is there some location or doc snippets regarding how the rights concept has been implemented (or how to administer it). I am looking forward to this feature and curious about how it looks like. Thumbs up! KR

[DanBrown47]

Has the documentation updated regarding this ?

[stnieder]

@shamoon Has the dev branch with this feature already been released and also released to docker hub? Do you guys have some timeline? (also if it is only vague)

[MrAlucardDante]

@shamoon Has the dev branch with this feature already been released and also released to docker hub? Do you guys have some timeline? (also if it is only vague)

Latest version has multiuser support ! Check the releases for more info

[artursuski76]

Users can only see documents they own (added or admin marked them as owners).

.../documents/views.py

def get_queryset(self):
        user = self.request.user
        if not user.is_superuser:
            return Document.objects.filter(owner=user).distinct()
        else:
            return Document.objects.all()

[shamoon]

Users can also be granted access by permissions to docs they don’t own

[cryptoluks]

Can someone confirm whether it's still necessary to manually allocate group permissions for each new document?

I'm trying to find a way to automatically grant access to specific users or groups for documents that possess a particular tag. However, it seems the permissions of the tag only pertain to viewing or editing the tag itself, and not the objects tagged with this "permission scoped" tag. Is that correct?

For instance, let's say we have entities such as mom, dad, child1, child2, grandma, and grandpa in Paperless. While sharing access to all documents amongst these users may not be too problematic, it would be incredibly helpful to have a feature that can help declutter documents for other users.

Or does anybody know if the owner/groups are exposed via the pre-/post consumer hooks? Then it would probably be possible to at least change the documents permissions based on the current tags?!

Thanks for the great work.

[shamoon]

Permissions from tags, corespondents etc don’t flow to the document. Yes, you can do this in a post-consume script.