thanks a lot Adam!

Your answer is really clarifying.


El dimarts, 20 febrer de 2018 0:01:37 UTC+1, Adam Cox va escriure:
> Hello Arnau, I hope this reply isn't too late too be helpful.
> The short answer to your questions is that in Arches permissions are 
> handled in different ways in different parts of the app, and, as you have 
> observed, permissions are not always tied to the standard Django 
> permissions objects. I will summarize things as best as I can, and 
> hopefully others can chime in if I'm missing something. I'll also get this 
> up on the documentation.
> I believe that all the observations you listed are explained by the fact 
> that in some cases, access to parts of Arches are determined by a user's 
> *group 
> membership*, and tested with the *group's name* hard-coded into 
> templates: 
> and 
> for example. This explains both the fact that creating a new group and 
> attaching permissions objects to it was not enough for you replicate the 
> Graph Editor group behavior, and the fact that though the System 
> Administrator has less "permissions", it can actually have more privileges.
> However, Arches has a much more fine-grained permissions handling system 
> for a different component of the app, the management of actual resource 
> data. To set these permissions you must use the Arches permissions manager, 
> which is in the Arches Designer as a tool available to Resource Models (not 
> Branches). (In other words, these permissions cannot be found or managed 
> within the normal Django admin interface.) In the Arches Designer you are 
> able to assign read, write/edit, delete, or set "no access" permissions on 
> a per-nodegroup-basis to any user or group in the system. In this way, you 
> could create a new group  and assign create/edit permissions to that group 
> for only one or two nodes in a Resource Model. One way I've used these 
> permissions is to give a group of users only access to the "condition 
> assessment" section of the resource model. That way a very wide range of 
> people can contribute condition assessment information, without being able 
> to change any of the core resource data.
> I hope that helps. I have found permissions to be an essential part of a 
> few projects I worked on, and in those cases often need to added some extra 
> functionality to accommodate the needs of the organization I was working 
> for. If you are doing the same, you may want to check out 
> which will give you an idea of how to interact with the nodegroup-level 
> permissions management.
> Please don't hesitate to respond with more questions about this; I'll be 
> quicker to respond and hopefully can get better general documentation up as 
> soon. Note also that there are some outstanding issues on github relating 
> to permissions that may be of interest to you as you work on this 
> development: 
> .
> Adam
> On Friday, February 2, 2018 at 2:56:11 AM UTC-6, Arnau Forner wrote:
>> Hello,
>> In the Django admin I see that there are some groups:
>>    - graph editor
>>    - application administrator
>>    - crowdsource editor
>>    - etc.
>> And also many permissions:
>>    - models | node group | delete
>>    - models | node group | read
>>    - etc.
>> For example the Application Administrator group has just one permission: 
>> models | node group | read, while Graph Editor has also delete and 
>> create/update permissions.
>> This is what I have observed:
>>    - When I log into Arches with a user that is part of the Application 
>>    Administrator group it has access to all functionalities
>>    - While when I log in with a user that is part of the Graph Editor 
>>    group, though it has more permissions granted, I can do less things in 
>>    Arches
>>    - If I make a new group and I grant the same only permission that the 
>>    Application Administrator group has, I don't have the same 
>> functionalities 
>>    available when I log in.
>>    - If I make a new group and I grant the same permissions that the 
>>    Graph Editor group has, I don't have the same functionalities available 
>>    when I log in.
>> *Regarding all this, we don't understand the behavior of permissions in 
>> Arches - django.*
>> *I don't see a direction correlation between granting permissions and 
>> functionalities available in Arches.*
>> *Are we missing something? Did we miss some configuration?*
>> *Is there some documentation of what do all permissions mean? *
>> We are currently working in a project to implement Arches and we need to 
>> create very specific users with specific roles in order to satisfy the 
>> project needs.
>> Thank you!
>> Arnau

-- To post, send email to To unsubscribe, send 
email to For more information, 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to