UPDATED 10/4/2012 – Added that the Module Level Admin and Developer access are only are specific to the commercial editions of Sugar.
One of the big things Sugar brings to the table is a strong ACL layer, which allows you to control the level of access users have to portions of the application.
While all the stock views in the application use this ACL, and any custom modules you build thru Module Builder leverage it automatically, what about if you create a new view? Or perhaps you have very custom elements that need to react differently depending upon how an ACL is set? Today and tomorrow, we will dig into how to do this at the module level, and then Thursday we’ll see how to do this at the field level as well for those using the commercial editions of Sugar.
Today, we’ll see how to determine admin access. There are actually two levels of admin inside of Sugar
- System-wide administrator
- Module specific administrator ( this one was added in SugarCRM 5.2 and is specific to the commercial editions of Sugar )
To determine the first, there is a simple method call on the User object to check this, isAdmin(). Note that if you are using an older version of Sugar ( before 6.2.1 ), then the call is is_admin() instead.
For the second case of checking to see if the user is an administrator for the selected module ( which is only available as functionality in the commercial editions of Sugar ), there is a simple call to the User object method isAdminForModule($module). Note the different syntax in the comments for pre-SugarCRM 6.2.1 usage…
You can also check to see if a User has Developer level ACL access for a module instead ( again only an option for the commercial editions of Sugar ). Remember that an System Administrator automatically inherits the Developer privilege, but a module level Adminstrator has to specifically be given Developer Access as well. To check for Developer level ACL access, you can use the isDeveloperForModule($module) User object call. Note the different syntax in the comments for pre-SugarCRM 6.2.1 usage…
These calls can be leveraged anywhere in the code base ( including Smarty templates! ), and you can substitute the usage above of $GLOBALS[‘current_user’] with a different User object to check to see if that User is an administrator instead.
Come back tomorrow where we will leverage the more fine grained ACL permission of seeing if users have access to view and change records.