Role-based dropdown not working

Hi Neil Conacher 

Definitely the Dependency SetOptions is a good strategy. Indeed we have had been configuring such features for different scenarios, including that issue.

In order to make it working like a charm you need to setup the custom sugarLogic isUserInRoleList.

Place the attached file into folder custom/include/Expressions/Expression/Boolean/

Then go to Admin -> Repair -> run the following actions:

• Quick Repair and Rebuild
• Rebuild Sugar Logic Functions
• Rebuild JS Grouping Files
• Clear Additional Cache

The sugarLogic function isUserInRoleList gets a list of roles by name and returns a bollean, example:

isUserInRoleList(createList("Tracker", "Sales Administrator"))

This way you are able to setup specific dropdown lists for specific roles disregarding the user within.

Regards

HI Andre,

I've had a look at this and would welcome your advice.

The scenario I have is around controlling setting of the account_type and there are 2 main elements which I will describe here:

1 ) account_type options:

Active Client

Inactive Client

Prospect

Partner

Lead

2) dependent changes

As part of the client take on process, we only allow a record to move to Active Client via another process outside the record UI.

General users can 'manage' a record and are allowed to change a record between Prospect, Partner, Lead (but not Active Client, Inactive Client)

3) Role based option

A limited set of users (defined by a role) are able to move a record from 'Active Client' to one of the other settings, but ideally should not be able to move any setting to Active Client

So my question on your approach is how to cover requirements 2) and 3)

Currently we have on DD list (account_type_dom) with the full set of options.

I'm thinking SetOptions would allow 'filtering' of the available options using only the one DD list but I'm wondering if I can also deal with the other logic which is essentially based on a combination of existing account_type on the record, business rules about what it can be changed to, and also the role of the user to determine the options presented to that user.

So in summary, I'm thinking still one DD list and then complex logic within the SetOptions dependency file.

Some logic examples would help me here (I tend to get confused between putting logic in the trigger and logic in the values as both appear to work in certain cases when I have used them in Dependency and Visibility situations)

Thanks

Neil

HI Andre,

I've had a look at this and would welcome your advice.

The scenario I have is around controlling setting of the account_type and there are 2 main elements which I will describe here:

1 ) account_type options:

Active Client

Inactive Client

Prospect

Partner

Lead

2) dependent changes

As part of the client take on process, we only allow a record to move to Active Client via another process outside the record UI.

General users can 'manage' a record and are allowed to change a record between Prospect, Partner, Lead (but not Active Client, Inactive Client)

3) Role based option

A limited set of users (defined by a role) are able to move a record from 'Active Client' to one of the other settings, but ideally should not be able to move any setting to Active Client

So my question on your approach is how to cover requirements 2) and 3)

Currently we have on DD list (account_type_dom) with the full set of options.

I'm thinking SetOptions would allow 'filtering' of the available options using only the one DD list but I'm wondering if I can also deal with the other logic which is essentially based on a combination of existing account_type on the record, business rules about what it can be changed to, and also the role of the user to determine the options presented to that user.

So in summary, I'm thinking still one DD list and then complex logic within the SetOptions dependency file.

Some logic examples would help me here (I tend to get confused between putting logic in the trigger and logic in the values as both appear to work in certain cases when I have used them in Dependency and Visibility situations)

Thanks

Neil