Hi all,
To set up a Change Managed folder in SAS DI is quite easy!:
Create a Change-Managed Folder in the Folders Tree - http://support.sas.com/documentation/cdl/en/bidaag/69032/HTML/default/viewer.htm#p0jwlqhvab11lrn130h...
Therefore, it should only require, on each managed folder (and only on them):
- Users with Project repositories: RM, and Check for the metadata. Optionally: R,W, and other full permissions for the data, except administer.
- Job deployers: RM and WM (+Scheduling role) should be enough.
But apparently it is not enough in my case for one specific project. There seem to be external components (not even in SAS Folders, but in the metadata) to administer permissions.
An example of an error during a check out:
MyUser@DOMAIN - User is not authorized to Checkout object QueryTable : 'Subquery_Results_46603 (sq)' (Id="A5VCWKRJ.CQ0000F3").
If I search by the Id or Subquery_Results, SMC cannot find the object.
A - Of course a SAS Foundation metabrowse can find the object in the metadata.
B - I can also find the object within SMC in Resource Management- By Type - and then Query Table or Prototype (for Prototype objects), etc.
On those metadata itemes I simply cannot provide permissions because there is no SAS Fflder. I can only provide permissions, individually, object by object (whithin option B), but there are hundreds of them. Not an option.
Therefore:
- correct permissions on those folders (as following SAS best practices) are not enough.
- Only if I apply permissions in ALL the metadata, through the Default ACT which is quite unsecure and unclear, then I can apply the permission on the object.
Hopefully you know more than I do, and one of you can help here: how can I apply, securely and manageable, permissions in the other metadata objects that are not under the Change Managed folders?
Thank you in advance,
Best regards,
Juan
Hello Juan,
When performing a Check out on an object like a SAS Data Integration Studio job, the job will almost always contain references to metadata objects that are not surfaced within Folders. Objects that are not surfaced in Folders tabs in SAS Management Console or SAS Data Integration Studio inherit permissions directly from the Default ACT (or the ACT that is designated as Default). Query Tables, Work Tables, Feature Maps, and Classifier Maps are examples of objects that fall into this category.
As you have discovered, if the user that is attempting to perform a Change Management task (like Check Out) is not granted CheckInMetadata permissions via an ACT, you will not be able to leverage Change Management in DI Studio.
Here is one solution:
This grants the CheckInMetadata permission for all dependent metadata objects, but denies CheckInMetadata to all registered users for all objects that do inherit permissions from folders. The result is that the only folders that will allow Check Out and Check In will be those that you configured based on the Change Management documentation.
If you prefer, you can limit the scope using an alternative like the following:
The only users that are granted any CheckInMetadata permissions in the Default ACT are those in the Change Management Users group, not all users. The only locations where users will be able to perform Check Out and Check In will be those you set up when following the documentation on using Change Management.
I performed testing and confirmed that these options successfully resolve the Check Out issues.
Regards,
Tom
Hello Juan,
When performing a Check out on an object like a SAS Data Integration Studio job, the job will almost always contain references to metadata objects that are not surfaced within Folders. Objects that are not surfaced in Folders tabs in SAS Management Console or SAS Data Integration Studio inherit permissions directly from the Default ACT (or the ACT that is designated as Default). Query Tables, Work Tables, Feature Maps, and Classifier Maps are examples of objects that fall into this category.
As you have discovered, if the user that is attempting to perform a Change Management task (like Check Out) is not granted CheckInMetadata permissions via an ACT, you will not be able to leverage Change Management in DI Studio.
Here is one solution:
This grants the CheckInMetadata permission for all dependent metadata objects, but denies CheckInMetadata to all registered users for all objects that do inherit permissions from folders. The result is that the only folders that will allow Check Out and Check In will be those that you configured based on the Change Management documentation.
If you prefer, you can limit the scope using an alternative like the following:
The only users that are granted any CheckInMetadata permissions in the Default ACT are those in the Change Management Users group, not all users. The only locations where users will be able to perform Check Out and Check In will be those you set up when following the documentation on using Change Management.
I performed testing and confirmed that these options successfully resolve the Check Out issues.
Regards,
Tom
Thanks a lot @TomH ! This helps a lot. Is this documented somewhere?
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.