Feeds:
Posts
Comments

Posts Tagged ‘dm_acl’

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:

Advertisements

Read Full Post »

Few days back I had read the chapter on Aliases. Since then I was eager to play with them. Ultimately I got my game plan ready. It was not a full-fledged plan which could give me a result but it was good enough for an initiative. I like flexible plans so that I can make changes as and when I feel, according to my comfort. Okay, lets stop the gossip and let the game start.

Setting up the field:

I will be using ACL Template to play with Aliases. As I am using ACL Template, I will also be requiring a set of users and objects.

As a first step I use the following DQL query to create a user.

create dm_user object
set home_docbase = 'ASSAPArchive',
set user_os_domain = 'infch02088',
set user_name = 'TestUser1',
set user_os_nam e= 'TestUser1',
set user_source = 'inline password',
set user_password = 'TestUser1'

Similar DQL queries were used to create four more users TestUser2, TestUser3, TestUser4 and TestUser5.

I like users to be part of a group.

CREATE GROUP TestUserGroup
WITH MEMBERS
(SELECT user_name
FROM dm_user
WHERE user_name like 'TestUser%')

No need to worry; there are no additional users with similar name in my repository. Now I have a group named TestUserGroup and it has five members named TestUser1,…..TestUser5.

Till here it was pretty easy. Isn’t it? But the game has not started yet. I am just arranging the players at their respective positions.

Before I create the ACL Template, I will need the Alias Set with the Alias that has to be used in the ACL Template.

CREATE dm_alias_set OBJECT
SET object_name = 'TestUserAlias';
UPDATE dm_alias_set OBJECTS
APPEND alias_name = 'TestUser',
APPEND alias_value = 'TestUser1',
APPEND alias_category = 1,
APPEND alias_usr_category = 1,
APPEND alias_description = 'Testing alias in ACL Template'
WHERE object_name = 'TestUserAlias';

Now I can go ahead with the creation of ACL Template. ACL Template is not same as ACL. It is actually a kind of ACL where aliases are used in place of users/groups. When such an ACL is applied to an object at runtime, the content server resolves the alias and creates a custom ACL with the resolved users/groups and the permissions in the ACL Template. ACL Template can be recognized as objects of dm_acl with acl_class = 1.

Below is the screen shot for the ACL Template created through Application Builder.newacltemplate_1

The field is set now.

Users : TestUser1, TestUser2, TestUser3, TestUser4, TestUser5.

Group : TestUserGroup

Alias Set Name : TestUserAlias

Alias Name : TestUser

ACL Template : TestACLTemplate

The Game Begins:

Let me go ahead with objects (of type dm_document) creation and apply the Template ACL to them.

CREATE dm_document object
SET object_name = 'TestObject1',
SET acl_name = 'TestACLTemplate'
SET acl_domain = 'ASSAPArchive'
LINK '/dmadmin'

FOUL!!!!!!!!!!!

[DM_QUERY_F_UP_SAVE]fatal:  “UPDATE:  An error has occurred during a save operation.”

[DM_POLICY_E_AS_NO_ALIAS_SET_USER]error:  “No default alias set found for user dmadmin. The following alias sets were searched: sessionconfig, user, user’s default group, server config, and policy (if applicable)”

Let me associate the Alias Set with the user, else there is no way the Alias can be resolved.

UPDATE dm_user OBJECT
SET alias_set_id =
(SELECT r_object_id
FROM dm_alias_set
WHERE object_name = 'TestUserAlias')
WHERE user_name = 'dmadmin'

The Alias Set is associated with the user. Once again I use the previously used DQL query for creating a dm_document object and applying the ACL Template to it. This time I was successful.

Lets check the permissions in the property page of the newly created object. A new custom ACL named dm_450003f080001517_80001100 is created and assigned to the object. It should be noted that the r_object_id of the ACL Template is 450003f080001517. Below is the screen shot of the property page. The new ACL has the resolved user name from the Alias Set.

testuser1permission_11

Second half:

The first part of the game is over. Now I need to change the user in the Alias set and check whether the change is reflected in the permissions of the new object.

UPDATE dm_alias_set OBJECT
SET alias_value[0] = 'TestUser2'
WHERE object_name = 'TestUserAlias'

The change in Alias Set is reflected in the object’s permission. So, a successful implementation of Alias Set is achieved. But a single Alias Set is not of much help in a practical scenario. Let me create one more Alias Set.

CREATE dm_alias_set OBJECT
SET object_name = 'TestUserAlias1'
APPEND alias_name = 'TestUser',
APPEND alias_value = 'TestUser1',
APPEND alias_category = 1,
APPEND alias_usr_category = 1,
APPEND alias_description = 'Testing alias in ACL Template'

The newly created Alias Set is now applied to the user dmadmin. Next time I created an object named TestObject2 and applied the ACL Template to it; the resolved user was as per the new Alias Set. Now I have two objects on which I had applied the same ACL Template and both have different users in their custom permission sets.

Analysis:

This situation is achieved because the Alias Set associated with dmadmin was changed before applying the ACL Template to the new object. Am I going to change the Alias set of dmadmin every time I apply the ACL Template to an object? That doesn’t appear to be a good idea. Further If due to some reason I need to reassign the ACL Template to the older object I may be into serious trouble.

Result:

The Alias Set was created and implemented along with the ACL Template. But the approach was not satisfactory for the practical purposes. A new plan has to be devised. Let me take a break now. I will be back with the new plan soon.

Related Articles:

Read Full Post »