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 André,

Thanks very much for this - I will have a look at it Friday and report back - sounds very promising.

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

Easy peasy!

• The main dropdown list (defined in the vardefs) must accomplish all options. This way Reports will be able to render any options accordingly
• You need to define a SetOptions dependency for values Prospect, Partner and Lead: isInList($account_type, createList("Prospect", "Partner", "Lead"))
• You need to define a SetOptions dependency for value Active Client and generic users: and(equal($account_type, "Active Client"), not(isUserInRoleList(createList("Special Role"))))
• You need to define a SetOptions dependency for value Active Client and special users: and(equal($account_type, "Active Client"), isUserInRoleList(createList("Special Role")))
  
• You need to define a SetOptions dependency for value Inactive Client: equal($account_type, "Inactive Client")

In short words, all possible scenarios must be considered by SetOptions dependencies, the way any SetOptions scenario has its specific DD list.

Good luck!

Hi Andre,

Thanks for your prompt response - I like the Easy Peasy part of it

I'll give that a go.

Just to clarify, I need to to have a separate SetOptions code block for each scenario rather than combining all the logic into one dependency block ?

Neil

Pay attention that the custom expression aren't apply in the mobile app for frontend perspective.

Yes, you need to configure individual SetOptions dependencies once the trigger attribute for each dependency has to have the sugarLogic function to execute its actions.

Thanks Cedric.

Do you know if this is something that Sugar aim to address going forward ?

Neil

Hi Andre

Just to let you know this is now working (just doing some quality control at the moment) and I'll upload the code for the benefit of the community when finished.

One question however.... what is the implication of ("edit", "save") in the 'hooks'

When I've been working with SetRequired I've tended to only use "edit" as a hook

Thanks

Neil

As far I know the hook 'save' applies only for dependency SetValue.

Regards