user acl's and calling dapi functions

Christina_Chan_(christinachan_-_(deleted))

I'd like to add some custom code so that when a user creates a new folder in the Enterprise workspace, the owner id (dtree.UserID) value is always set to a dummy account which no one uses. We need this feature because we don't want any individual user to have "forever" access to an object even if she moves to a completely different department and should no longer have access to her old department's information.

I tried this code:

/*** call a function to get the unique ID of "DefaultOwner" user account ***/
result = $CPSBase.CPSFunctions.getDefaultOwnerID(createInfo)
if node.pVolumeID == -2000
node.pUserID = result.ID
end
status = DAPI.updateNode(node)

but I'm getting this error returned from the Dapi function: "Control accessibility error. Not enough permissions."

The user has ACL permissions in the parent folder of : "see/see contents/modify/editattributes/additems/reserve/deleteversions".

Can anyone shed some light on why the dapi call is failing? Surely all the permissions above should be enough to do a simple ownerid change during the create process.

Find more posts tagged with

Comments

Appu_Nair

Here are a few tips.If you were doing the same operation thru the livelink GUI livelink will show you the 'Permissions' function link if you are in the follwing category.

a)You are the user 'Admin'

b)Your userid has SA privs on the profile.

c)Your id can be resolved on the ACL of the object either explicitly having 'Edit Permissions' or thu membership of a group having 'EP" on the object.I think you are missing that in your prgCtx in your code.

Secondly-If you remove the owner on the parent ACL all suceeding nodes will have 'No Owner'.I see many companies doing this so that the owner field does not have a lot of unwanted perms.

Thirdly-Many of us use instead of DAPI the lliapi node implementation.It is more error proo than DAPI

Fourth-many of us in code use a 'admin' context to drive operations like this.If you search builder you should see 'GimmeaPrgCtx' script.Kindly peruse recent postings by a stalwart Kyle Swidrowich in this forum on how one should use the administartive context.If not used carefully it can be detrimental.

Christina_Chan_(christinachan_-_(deleted))

Thank you for the tips -- a few questions if you would allow.....

If I understand you correctly, point C seems to confirm that a user would indeed require "edit permissions" access in order to change the dtree.UserID value.
This is problematic, as I would not want the vast majority of our users to have "ep" level access to folders!!

As to your 3rd point, if I am correctly understanding point C, then even using lliapi does not solve the error if the users do not have "ep" access.

I am very interested in your 2nd tip, of having "no owner" -- I did not know this, and yet it makes perfect sense and would perfectly solve our requirements!!
I will test this feature more fully.

Thanks again, Mr. Nair!

Appu_Nair

When they teach knowledge fundamentals

They teach you that the owner is the only field

That is not inherited everything else on the

Acl is.So a better permission matrix is to have

Owner S,SC the group a group having some

Say in the purpose of the container,maybe S,SC again really

All access controlled by the assigned access

ListThis way the new owner (creator)has only

S,SC and you would sleep easy if the 'Owner'

Left.There is a poetic justice in seeing

The owner,functionally it is the highest

Bitmap of perm that wins that is defined

On the node's ACL.As you say everybody,s

Requirements cannot be reconciled so OT

Gives you that much flexibility in doing that

Sent from my iPhone

On Apr 19, 2011, at 7:44 PM, "eLink Entry: Content Server Builder Forum" <componentbuilder@elinkkc.opentext.com> wrote:

Further clarifications please Posted bychristinachan (Chan, Christina)On 2011/04/19 20:39

Thank you for the tips -- a few questions if you would allow..... If I understand you correctly, point C seems to confirm that a user would indeed require "edit permissions" access in order to change the dtree.UserID value.
This is problematic, as I would not want the vast majority of our users to have "ep" level access to folders!!As to your 3rd point, if I am correctly understanding point C, then even using lliapi does not solve the error if the users do not have "ep" access.I am very interested in your 2nd tip, of having "no owner" -- I did not know this, and yet it makes perfect sense and would perfectly solve our requirements!!
I will test this feature more fully. Thanks again, Mr. Nair!cc
[To post a comment, use the normal reply function]
Topic: user acl's and calling dapi functions
Forum: Content Server Builder Forum
Livelink Server: knowledge-wlweb01

Greg_Griffiths

I think you could add the code either into one of the scripts in WebDoc:DocNode:Folder such as _SubclassCreate2Post or perhaps a call back (WebNode:ComponentNodeCallBacks:CBCreate) and have it do the following :

If ParentNode is Enterprise Workspace then

get the dummy User ID

get an Admin Context

use the Admin Context to do a DAPI.GetNodeByID

update the owner and save the changes using the Admin Context

check that the update worked

delete the Admin Context

end