eikek
Hide Collection Settings
Hi,
is it possible to deny access to Collection Settings for some users? e.x. i don't want my children to access the collection settings since they could add additional users or change the destination folder of my private document sources.
When i upload a Bank Statemant after, it will not go into my "private" folder, my child has no access to, but into a "child-private" folder.
Therefore a "collection admin" flag or something like this would be great.
It's not possible to hide it or deny access for anything. Docspell started with the idea that all users in a collective are "equal" and trust each other (like it usually is in small groups or families). Current solution is to properly educate your children 😄 (mine is to little for that… I can say this easily :)).
I can see the use case here and there is also accidental change by not so experienced users. I'm a bit scared to add "real permissions" tbh, because this is quite some effort affects new stuff as well. But maybe something can be done, like having some sort of permissions but only manageable by the command line tool, for example. Then an "admin user" can add/remove permissions for any user on the server (not just for one collective).
I would try to implement such thing, but i am absolutely not familiar with skala and elm. And they seem to differ hard from common languages like C, Java, Python, Ruby, Go, etc.
They differ and have lots of things in common :-).
An important point for me is, that every more complex feature will make the software more work to maintain and often also more complex to use. While I can see that access restrictions are useful, I still think for a personal tool, it is not so important. The base assumption from the beginning is that people in a collective trust each other. If you need to have complex scenarios supported "first class" with many users, access control etc, docspell is really not the right tool. There are many other document management systems that have lots of features in that area.
So I need to think more on what can be supported and how, such that it doesn't have too much impact. I think it will always be a secondary goal. Here it could be enough to implement restrictions based on the api level. This shouldn't require a lot of changes in the code, but has implications on usage. Now you are able to deny access to certain apis, but some features need a certain combination of apis - it is then very easy to misconfigure the application, which will result in issues and complaints - rightly so, because it doesn't really work well. OTOH restricting access to certain apis could also be achieved via a reverse proxy - so it might not add that much value after all.