We are developing a series of contact doctypes using google contacts format ( you can see it here Extension of contacts to synchronize with Google contacts ), so that later we can make it available as a means to synchronize with google contacts as a module.
Contacts are central to our application ( dharma_center_erp ), so we have different custom fields extensions organized functionally by doctypes in order to fulfill different information needs according to roles. For that, we use a master doctype Contact with several child doctypes that have different access possibilities for the different roles / child doctypes that can later be added. Any role in the system can see different parts the contact doctype. We have organized functionally in custom fields groups, doctypes with the information to be accessible to different managers and also the contact itself as Website user ( since he / she are going to be able to update some of its own contact information via website ). My doubt is: how to enable / disable users to access different child doctypes of contact doctype according to profiles, does it have to be by code or is it possible using only the profiles associated with the doctypes? Note that the center’s director role is able to see and change almost all the info. The website user ( the contact itself ) can see mostly all the info, except notes and some internal contact child doctypes that have info only available to managers. I’ve noticed that there is also possible access segregation via access levels, but i am not sure how to correctly apply it. The information regarding accesses matrix is present in the attached image.
Please give us advice on how to accomplish the following features according to the image:
Do not allow the Website user to see notes and some child doctypes that are for use by internal staff as a readable / writable field of contact doctype;
Allow only health info child doctype to be readable by specific roles and readable / writable by the website user;
Allow the reception to see, change only general contact information and the internal fields / contact child doctypes;
Allow only the work preferences of the contact to be edited by the website user, but to be seen by some of the profiles listed above.
About the other permissions for different roles in the different child Contact’s doctype, they seem to inherit the Contact’s permissions, is it possible to apply to them specific role access? If so, how?
For the moment, we are planning 3 kinds of accesses:
Internal access - Making use of built in ERPNext’s forms and security the most possible for people who belong to the organization;
Optional external access to contacts for people who belong to the organization according to profile via google contacts;
External access for people outside the organization accessing via existing website outside ERPNext: For this we need to have available the doctypes to communicate via REST API;
For the moment, the option of building web pages is not yet to consider. We want to keep the application and the use of Doctypes as compliant as possible, to take advantage of existing REST API infrastructure associated with it. Is it possible to use an expression on a field of the contacts that will hold a link to a child table having health info and controlling the access via an expression on the permissions → depends on, like in the following image?
OK, i kind of reorganized the permissions on a set of levels from the most permissive on the left to the less permissive on the right. It works well for most of the cases. Please note the case of Spiritual Program Coordinator.
For the cases that are shown in red which would mean gaps between levels i tried to create levels in permissions to the users not allowing them to read or write, but i there is a validation that does not enable me to do this. So please note on the schema, the Spiritual Program Coordinator on level 3.
If this validation was an alert but not mandatory, it would be possible to use all structure already developed and this schema of permission set with the possibility to skip a level so that it could be used in further ones.
@WhiteKarma really hard for me to evaluate all this information. I would suggest not to obsess with permissions first, just get a simple module going and the restrict based on need.
Will be happy to answer a specific question, but its hard design the permission model based on your spreadsheet.
