Jump to content


Member Since 25 Mar 2017
Offline Last Active Sep 22 2017 03:58 PM

Posts I've Made

In Topic: Some Modules Not Visible

01 April 2017 - 08:28 PM

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



- 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.



In Topic: Some Modules Not Visible

01 April 2017 - 07:28 PM

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...



In Topic: Some Modules Not Visible

01 April 2017 - 06:32 PM

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)



In Topic: Some Modules Not Visible

30 March 2017 - 08:47 PM

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.



In Topic: X2Workflow Design Studio

30 March 2017 - 06:59 PM

Hi Raymond,


Sorry about that, it was me being stupid  :rolleyes:. Once you drill down into a specific workflow the export option does appear on the left. I was looking at the workflows list instead and there was only an import there (which makes perfect sense).