Feeds:
Posts
Comments

Posts Tagged ‘Alias Set’

This query is raised by many people who read my earlier posts on Aliases. Why do I need more than one Alias Set? Let me try to answer this question. As per my understanding of Aliases I can clearly visualize its use and benefit while using multiple Alias Sets. Most of the people who raised this question had a mindset that the Alias will make their work easier as it will act as a place holder and they will be able to replace the value and use the same Alias set again and again. I had tried the same as mentioned in my first post on Alias.
I had created an Alias Set and an ACL Template using the Alias. This ACL Template was applied on a document. The Alias was resolved and the permission defined in the ACL Template was granted to the user defined in the Alias. Later when I updated the Alias value with a new user name and applied it on a new document, the new user was granted the permissions in the ACL Template. The behavior was as per expectation. What about the permission on the first document? It was found that the user name in the permission set of the first document was updated as per the Alias Set. In other words, I was not able to grant permissions to two different users on two different documents using one Alias Set. The change in the Alias value was reflected even in the Permission Set on the old document. In this case there was no other option but to use more than one Alias Set. More precisely I needed as many Alias Sets as the number of users.

Why?
If I don’t use Alias Sets and ACL Template and try achieving the same situation then I need to create ten different ACL for ten different users. While using Aliases I need one Permission Set Template and ten Alias Sets. So, there is no reduction in the efforts as such. The benefit can be seen only while managing the ACL. In the previous case if the permission has to be changed (lets say from read to write), we need to update all ten ACL. In the later case updating the ACL Template will give us the desired result. Just to note that the ACL cannot be updated through DQL if you thought that all the ten ACL can be updated through DQL by using an appropriate Where condition. As the number of ACL grows, the ease in managing the permission using ACL Template becomes increasingly prominent.

When?
Does that mean I can use ACL Templates and Aliases in every case? The condition being that all the users need the same permission on the respective document. In the above case all the ten users have the same permission on the respective document. ACL Templates and Aliases can be really helpful in granting permissions to specific users who can be very large in numbers as compared to limited number of groups.

How?
In a recent implementation I have used ACL Templates and Aliases to grant permission to user and his superiors in the organization hierarchy. I have one Alias Set per user and it defines his superiors at various levels through different Aliases. The Alias Sets are created, associated and updated through a TBO. The same Aliases are also used in the workflow to decide the performer of various activities. In absence of the Alias Set I would have to fetch the users’ superiors and set them as performers of various activities in the workflow using a DFC code. As evident, Aliases have helped me in more than one ways.

Related Articles:

Read Full Post »

Here is a new attempt to implement Alias Set and ACL Template in a way that can be more meaningful. The Major drawback in the previous implementation was that the Alias Set was associated with a single user. As the ACL Template was always being assigned by the same user, every time Alias was resolved to the same value unless the user was associated with a new Alias Set.

Alias Sets can be used in a much better way if the Alias can be resolved to different values at different instances. One of the easiest ways to achieve it is by associating the Alias Set directly with the Sysobject. If it was followed in previous case, different ACLs could have been applied to different Sysobjects while using only one ACL Template and multiple Alias Sets.

The attribute of dm_sysobject that is responsible for its relation with an Alias Set is r_alias_set_id. It stores the r_object_id of the Alias Set. It appeared to me that the only possible (and meaningful) way of associating a Sysobject and an Alias Set should be through DFC. I started my search for a method of IDfSysObject that can be used for the purpose. But I failed myserably in my effort. I couldn’t find a method as per my expectation. Finally I resolved to my ultimate rescuer, Google. I found a post regarding Permission Set Template by Johnny. In his comments he has mentioned, “I manually set the r_alias_set_id directly against the object that I am assigning the PST to.” I was surprised at the ease and simplicity of his statement. I was trying to achieve the same. I had an understanding that the r_ attributes are read-only with r_version_label being an exception. Still I descided to try the setString method of IDfSysObject.

The Field Setup:

Five Users created: TestUser1, TestUser2, TestUser3, TestUser4, TestUser5.
Five Alias Sets: TestUserAlias01, TestUserAlias02 …. TestUserAlias05.
An ACL Template: TestACLTemplate

Each Alias Set has a corresponding user name as the Alias Value. The process of creating the set-up was similar to that in the earlier case.

The Game:
Following is the fragment of DFC code used. Five objects of type dm_document are created, they are associated with corresponding Alias Sets and finally the ACL Template is applied on the newly created objects.

***************************************************************

for(int i=1; i<= 5; i++){
IDfDocument document = (IDfDocument) dfSession
.newObject("dm_document");
if (document != null) {
document.setObjectName("TestAliasObject_00"+i);
document.setContentType("pdf");
document.setFile("C:Test.pdf");
document.link("/dmadmin");
// can be a business logic
document.setString("r_alias_set_id",
dfSession.getObjectByQualification
("dm_alias_set where object_name = "
+"'TestUserAlias0"+i+"'")
.getObjectId().toString());
document.setACLName("TestACLTemplate");
document.setACLDomain("ASSAPArchive");
document.save();
}
}

***************************************************************

The main concern was the highlighted statement. Before reading Johnny’s post there was no reason to believe that it can ever work.

It was established that the understanding regarding r_ attributes was a misconception. At the least there is one more attribute which is an exception to the rule. Updating r_alias_set_id through DQL was also successful.

Anyway, my part in the game was over and it was time to verify the results.

Result:

testaliasobjects

Benefit:
Consider a case where the permission of all the users has to be changed from Write to Version. In the current set-up it can be achieved by updating only the Template Permission Set. If instead ACLs were used, all of them would have to be updated individually.

Related Articles:

Read Full Post »

Older Posts »