· May 4, 2018 1m read

Implicit Privileges of %Developer Role in 2017.2

In old Caché versions it was possible to create a new role based on predefined %Developer by copying it and adding some resources as needed. It was true at least from 2010.1 to 2015.1.

After upgrade from 2015.1.4 to 2017.2.1 it turned that it's only partially true now. User with a "New-Developer" role can enter Studio and open existing cls/mac/etc for editing and everything is OK unless he tries to create something new (Ctrl-N), than he gets a pop-up with %msg: <User xxx does not have enough privilege to execute stored procedure %CSP.StudioTemplateMgr_Templates>

The solution found was simple: user defined roles based on %Developer should be assigned to %Developer rather than contain all its resources inside. The simplest way to achieve it is to make a "New-Developer" role a member of %Developer. To be fair, InterSystems docs always contained a note:

InterSystems recommends that you do not modify predefined roles. Rather, create a new role based on the predefined role and modify the role that you have created.

but it was not clear enough how it should be based: by copying or by assigning. In modern Caché versions only the last way seems to be valid.

Discussion (3)2
Log in or sign up to continue

WRC answered that:
1) The reason of the error with "CSP.StudioTemplateMgr_Templates" is because the "CSP.StudioTemplateMgr" class is owned (has Owner = "...") by %Developer. So a user with %Developer had no issue executing this stored procedure "Templates". Prior to 2016.2 the class did not have the Owner specified.


2) This change was intentionally added for security reasons when Atelier support was added to Cache'.

(1) reassured me that I had taken the right way to solve the issue.
I didn't understand (2), but... 

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.