Jump to content
X2Community Forums

Recommended Posts

Hi Werner,

 

It sounds like the user's Role may not have permission for the Reports module. You can update their Role's access to that module from the Edit User Permissions & Access Rules page, accessible from the admin panel.

 

Raymond

Link to post
Share on other sites

Hi Raymond,

 

That's the funny thing... with a fresh install it seemed like you guys were following a philosophy of open security. In other words, there were no roles or groups predefined and any new user that you created automatically had access to everything (well everything except the Reports and Charts modules). I then started playing around a little with your security model to lock things down a bit and created a couple of groups with users assigned, and then a role with a group assigned to it in turn.

Up to this point everything was working as expected and you were following a standard practice security structure.

 

Logging in with a user belonging to the assigned group however delivered unexpected results. I expected to only see the modules in the top bar that the group (through the linked role) either had view or edit rights to, but instead it still showed all the modules. You could even access a "banned" module and the form structure would load but without any fields to complete. With some of the other "banned" modules you could go ahead and create a new record but when trying to commit the record it would just warn that some fields were required and the changes couldn't be committed (even though those fields were filled in but just obviously by a user without the relevant permissions).

So it seemed like the security was being applied but at a very granular level (field level) and not cascaded higher up the chain (form and module level), which caused a confusing UI for the average user to work with. Instead of just taking away (hiding) the UI components completely that they didn't have access to, it still allowed them to see and interact with those but just in a lopsided, unintuitive fashion.

 

When creating/managing the roles and groups there were also some unexpected results:

- You could not designate a group as an administrators group. So I could not enable multiple users with the capability of accessing the Admin link in the top bar to manage the environment. Only the primary user signed into the system first had those rights.

- Any edit permissions assigned to a role would just disappear after saving it. You had to first create the role, assign view permissions to it, save it and then you could assign edit permissions that would stick. One would think that as edit permissions by its very nature automatically included view permissions, you would not have to perform the double assignment every time.

 

So to come back to the original point  ;), the users who could not see the Reports and Charts had no roles assigned to them that would have blocked their display in any way.

 

Werner

Link to post
Share on other sites

Hi Raymond,

 

Okay, I resolved some of those points in the meantime.

 

- I found the option to designate a particular role as an admin role. You have to go to Edit User Permissions and Access Rules section (EUPAR) after initially creating the role in the Manage Roles section (MR). So this one is all good.

- I also saw that you could fine-tune permissions and access a lot more under EUPAR, but it doesn't seem like its being applied correctly...

 

    ...as an example I selected the same role as previously created and looked at its settings in EUPAR. Nothing was selected even though I had assigned both view and edit permissions under MR for the Leads and Accounts modules (and nothing for the rest of the modules). I then manually selected View and Create permissions for the Accounts and left Update and Delete off. I only selected View for Leads and all others were left off.

Logging in with a user in a group with this role assigned, I was still able to update Accounts records without any problem (both inline and in edit mode) even though it had not been explicitly set.

I went back to EUPAR and added Create permissions for Leads as well but still couldn't create any new records under Leads with this user account. I made sure to refresh any possible caching effects by logging out and in, clearing the total browser history and cache, and still its a no-go.

 

So definitely anomalies happening between assigned EUPARs and end-results.

 

Werner

Link to post
Share on other sites

Hi Werner,

 

Ah very interesting, I'll need to try to reproduce your Role settings and see about possible issues. One thing to be aware of that may be skewing your permissions is the "Default Role." This Role is applied first, and must be the least permissive in the system. If the default role can do something, than any user can do that operation, regardless of other roles put on top of it. Please let me know if you believe this may have been impacting your testing.

 

At a future release, we'd like to compact the two Role screens into a single view, which should drastically reduce the work required to manage roles in the system.

 

Raymond

Link to post
Share on other sites

Hi Raymond,

 

Default role? Aaah, I will check it out and report back...

As I indicated in an earlier post - this is a newly spun up test environment that I configured to use as a quick test lab environment. Platform is Debian 8.7, mysql 5.5.54, PHP 5.6.30 and Apache 2.4.10 (Turnkey LAMP 14.1 with updates) installed with X2CRM 6.5.2 on top. So all of my above observations are based on that.

- User Management > Manage Roles: No roles defined at all

- User Management > Groups: No groups defined at all

- User Management > Manage Users: Single user (admin)

 

Werner

Link to post
Share on other sites

Hi Raymond,

 

Okay, found the Default role and the answer is that it definitely has an impact.

Let me understand the model then - Default overrides everything? So this goes against normal expectations as one would assume that any additional roles added to the baseline would build on top of it and not be superseded by it. Well I suppose that is true depending on the perspective of why the default role is there in the first place... to lock things down or to open things up.

If its a lock down (as per your explanation), then out-of-the-box the Default should have nothing enabled (except if you are a user/group that has been assigned an admin-enabled role), as Default is suppose to be the most restrictive role of them all. Admins in a newly installed system must then be educated that its their responsibility to open up features to users/groups as they require by building out a proper user management model, otherwise nobody will be able to access anything.

The message is then clear - the system is in lock down unless you allow for access (the same as a firewall approach, which is the safest and forces you to consider what you open up to whom).

The drawback of this approach is that you are going to make life difficult for the unskilled admin to get going with a newly installed environment if they don't understand how to build a user security model.

 

The flip side is have a default which is completely non-restrictive. New admins will be able to get users working in the system quickly - they just have to add new users and not be concerned about security - and then continue locking down the system from there (if they require it to be).

 

From my initial observations you have something that's kind of in-between these two approaches, which actually causes more confusion than following one or the other of the two above options because at first glance it looks like you are following an open system (as per my initial comment) but actually you are not, because you have the Default role defined which gives you access to some things but not all.

 

With a fresh install you should see the following (assuming we want to go for the locked down option):

- Manage Users: A single admin user who has been assigned to the admin role

- Manage Groups: Empty list

- Manage Roles: A single admin role with everything enabled

- User detail page: An indication of current group(s) and role(s) membership

This will make a lot of sense to most admins who have been around for a bit and they will be able to very quickly move forward from there - knowing exactly what they currently have and being able to build their own custom model.

 

And yes, I agree with you... having roles configuration displayed in a single view instead of the current split view will also make the structure a lot more evident.

 

Anyway, that's my two cents  B)

 

My testing continues and I will give feedback accordingly...

 

Werner

Link to post
Share on other sites

Okay findings are as follows...

 

Config (in this sequence of steps as sequence change will have an impact on results):

- Created a custom module called Unit with one extra field called Registration Number

- Created a group called Sales

- Created a role called Sales

- Assigned Sales group to the Sales role and added all fields for Accounts and Leads for both viewing and editing

- Deselected everything in the Default role's access and permissions settings

- Deselected everything in the Sales role's access and permissions settings except for Accounts (view + create) and Leads (admin)

- Created a user called Sales1 and added user to the Sales group

 

Results logging in as Sales1:

- Can see the Leads, Accounts and Unit links in top bar and nothing else

- Can view, create, edit and delete records in Leads

- Can view and create records in Accounts but cannot edit or delete

- Cannot view, create, edit or delete any records in Unit even though I can click on the module name in top bar. It just displays an empty list.

- So all in all except for the display of the Unit link everything is working 100% as configured and expected

 

Caveats:

- Any new fields created for new modules are automatically added with view and edit permissions to existing roles and hence my comment about sequencing being important unless you go back after the fact and clean up after yourself

- The view and edit permissions under Manage Roles function independently from the permissions under Edit User Permissions and Access Rules.

   As an example if you omit to add fields under the edit permissions for a particular module (in Manage Roles) and you then go and assign rights (in Edit User Permissions and Access Rules) for that module (let's say admin), you will be able to view and delete records in that module but not do anything else. Now if you understand the system, its doing 100% what you asked it to do, but for someone unfamiliar with it, things can become confusing very quickly.

- Not all modules are represented in the Edit User Permissions and Access Rules list. Charts is currently missing and can therefore not be configured for any custom roles.

- Some modules (Reports) have got limited configuration options. You can only set view rights and full admin rights, so its an all-or-nothing situation.

 

Werner

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...