Force checkout in Data Integration Studio

[FK21]

Hello,

first of all: I know this might not be the best forum to place this question, but I did not find a more appropiate one. So, if one of the admins knows, where to post this question, feel free to move it.

Now, having said, this my question is as follows:

Is it possibl to set a sort of parameter in Data Integration Studio (4.906 under SAS 9.4M8) which forces users to check out an obect, before they are able to alter/modify it?

I stumbled upon the fact, that you can alter any given object (e.g. a Job) without having to check it out in the first place!

This can lead to missing audit trails. In case of using the check-in/check-out facility, you would be able to view the the (modification)history of a Job (right click on the job, then choos "History").

For example: I created a job, "LS_KFZ_00_BESTAND_SCHADEN_REMOVE_CURRENT_MONTH".  Then, I DID NOT check it out and went on to chang the content of the job by adding several transformations and removing others in the job. After I saved it, I got the following result:

I only see the "creation" of the job in the history: 

So my qustion is: how can I prevent users from modifying jobs or other metadata objects, which are in the realm of DIS, if they are not properly checked out?

[DavidGhan]

You need to set the correct permissions on objects to ensure that changes can only be made on the objects when they have been checked out. You will want to grant ReadMetadata and CheckinMetadata permissions on those objects and deny other permissions. More details on how to set up change management are detailed here:

https://go.documentation.sas.com/doc/en/bicdc/default/bidaag/p0jwlqhvab11lrn130hwdiq02tsi.htm

[FK21]

Hi @DavidGhan ,

thank you for your remarks. I did properly set up the metadata rights, meaning: only those who are eligible, i.e. allowed to modify meta data via DIS can do so (let's call this group "developers"). However, what I am looking for is a way/method, that developers also do not have the means/possibility to alter/delete/update any metadata object, if the did not check it out in the first place, even though they are generally allowed to modify metadata objects.

This, so it seems to me, is not realizable with DIS or metadata granting schemes, respectively.

[Patrick]

This is very much possible and I've worked in such environments. Suggest you read @DavidGhan's comments once more as well as the link he provided. This is just about getting the metadata security model right. 

[Quentin]

Interesting question.  I don't know anything about version control in DI studio, but I suspect you may be right that it's not possible to do what you want.

From the little I've read, version control in DI studio works with plugins to third-party version control applications (git etc.)  

Normally the version-control application would have access to the files that are under version control, so I can see how they could be locked until checked out.  This is how Microsoft TFS works.

But with DI studio, the files you have under version control are metadata stored on the metadata server, so I don't think the version control application would be able to lock them.

I guess the question would be whether the DI studio plugin to the version control system could be smart enough do this for you. The plugin knows where the metadata object is.  So in theory, the plugin could change the metadata permissions to an object when it's checked in to make it read-only, and make it writeable when it is checked out.

Tagging  @MichelleHomes as her company Metacoda are experts in metadata security.  I wonder if they have seen a helpful approach for integrating version control with metadata permissions in a ways that forces developers to check out a metadata object before editing it.

[DavidGhan]

The Change Management capabilities of SAS Data Integration Studio are not a version control system and are not tied to a third party version control system. The purpose of Change Management for DI Studio is described in the documentation thus:

With change management, most users are restricted from adding or updating the metadata in a change-managed folder in the Folders tree. Authorized users, however, can add new metadata objects and check them in to the change-managed folder. They can also check out metadata objects from the change-managed folder in order to update them. The objects are locked so that no one else can update them as long as the objects are checked out. When the users are ready, they check in the objects to the change-managed folder, and the lock is released.

In order for this to work the metadata permissions for all users under change management need to be set so that they have permission to readmetadata and checkinmetadata but they must also have other permissions denied (writemetadata, .. etc)

[Quentin]

Thanks for that correction, apologies for my mistaken assumption that that was using 3rd party version control.

On closer read, I see that, as @Patrick mentioned, this is indeed covered in the document you linked to.

The key point I missed was:

• For users or groups who should be authorized to work in the new folder, grant ReadMetadata and CheckInMetadata permissions, and deny other permissions.

So using this feature, the developers would not have writemetadata permission to the jobs in the main (controlled) folder.  Thus they would need to check them out to their personal project to edit them, where would have writemetadata permission to objects in their repository, and then later could check them into the main controlled folder.

This sound to me like what @FK21  wants.

[Quentin]

---

@FK21 wrote:

Hi @DavidGhan ,

thank you for your remarks. I did properly set up the metadata rights, meaning: only those who are eligible, i.e. allowed to modify meta data via DIS can do so (let's call this group "developers"). However, what I am looking for is a way/method, that developers also do not have the means/possibility to alter/delete/update any metadata object, if the did not check it out in the first place, even though they are generally allowed to modify metadata objects.

This, so it seems to me, is not realizable with DIS or metadata granting schemes, respectively.

---

I think you and I both misread David's response the same way.  If you read it again, you'll see that your Developers group should NOT have writemetadata permission to these objects.  The lack of writemetadata permission is what forces them to check out an object before editing it, presumably.