ARSDOC Update Error

[cpalmer]

Hello,

I had posted this as a reply to someone else's post regarding the same topic.  It occurred to me that I should have post this as a new topic, so I have removed it as a reply to the other post and am posting as a new topic.  Any help at all would be most appreciated!!!

I have been trying to run the arsdoc update command and am getting "The user is not permitted to perform the operation."   

The user has administrator authority to the application group, including update access; as well as administrator authority to the folder.  The folder only has one application group.

The command I am running is /opt/ondemand/bin/arsdoc update -h CMODServer -u CMODUser -p xxxxxxx -F /home/xxxxxx/OA1912test -v.

The parameter file contains:

[-f "OA1912_Corrections"] [-i "WHERE MemberNumber = 'ABC123'"] [-n "MemberNumber = 'XYZ321'"]

The results I get back are:

11/07/13 11:59:18 : Starting arsdoc.  Version:  8.5.0.6

11/07/13 11:59:18 : /opt/ondemand/bin/arsdoc update -h CMODServer -u CMODUser -F /home/xxxxxx/OA1912test -v

11/07/13 11:59:18 : Attempting login for userid 'CMODUser' on server 'CMODServer' ...

11/07/13 11:59:18 : Login successful

11/07/13 11:59:18 : Searching for folder 'OA1912_Corrections' ...

11/07/13 11:59:18 : Search successful

11/07/13 11:59:18 : Searching for documents in 'OA1912_Corrections' ...

11/07/13 11:59:18 : Querying database with SQL string 'WHERE  MemberNumber = 'ABC123''

11/07/13 11:59:18 : Search successful

11/07/13 11:59:18 : Updating 2 documents with
MemberNumber=XYZ321

11/07/13 11:59:18 : Update unsuccessful

11/07/13 11:59:18 : The user is not permitted to perform the operation

11/07/13 11:59:18 : The error occurred on line number 1.

11/07/13 11:59:18 : arsdoc completed.

I actually have a list of over 1600 records that need one index value updated, but wanted to test it first with just one record in the parameter file.

I've exhausted all of my ideas and searches for a solution to this.  I'm hoping it is something very simple that I am just overlooking.  I would appreciate all help.

Thank you,
CJames

[Alessandro Perucchi]

Hello CJames,

Well it is not because a user is "Admin" of the application group, or full admin, that it means he can do what he wants!

Here is what you could check, is the flag "Update Document" set for this user and Application group? An Admin doesn't have per default "Update right", you need to explicitly give it to him.

The second place you can also look is in the application group, the field definition of your field "MemberNumber" does it have the flag "Updateable", if not, then even with the most powerfull admin with all right, you won't be allowed to update the field.

I hope that helps a little bit.

Sincerely yours,
Alessandro

[cpalmer]

Thank you Alessandro for responding.  I just double-checked all of the settings.  The CMODUser is a member of the Admin group, and the application group MemberNumber field has the "Updatable" parameter checked.

I have tried running this with the CMODUser as user type "User" and also as user type "System Administrator." 

I tried unchecking the "Updatable" field and ran it just to see what type of message I would see.  I got a " Index values that have been stored in database field 'MemberNumber' cannot be changed."  I then rechecked the field and reran the command and got "The user is not permitted to perform the operation." 

I am truly at a loss here.  Is there any type of setting in CMOD that would not allow updates?  This is our first time trying to do any type of update.  Always before, we have only done loads or unloads.

Again, thank you for your help.

CJames

[cpalmer]

Here is what you could check, is the flag "Update Document" set for this user and Application group? An Admin doesn't have per default "Update right", you need to explicitly give it to him.

I forgot to mention that I did check this setting as well.  The flag "Update Document" is set for this user and Application group.

[Alessandro Perucchi]

Hello cjames,

wow, really strange... :-(

What can I say? how are the rights given to this user? to the user directly or to some groups? or a combination of user and group rights?

1) If the rights of this user is done directly on the user permissions, and it still doesn't work, then I'm out of idea... except... does the field has some special function in the application group? (like "segment", "Size", ...?)

2) If the rights of this user is done via groups, then here it is a little bit tricky, you need to look at all your groups and verify which of them is giving the permission to your application group, and then from this subset of groups take the one with the lowest GID (Group ID), and this one will give the permission of the application to the user. Then change this group to the correct permission, and check.

3) If you have a mix between user rights and group rights, then check where is located the permission of this application group, if this is the on the user, then check point 1), if the permission is set in the group, then go to 2).


Another idea that struck me... do you have any security user exits? Maybe, depending on what they do, it might have an influence on the rights that you can give or not...

If after all of that, it still doesn't work... or you cannot find any good explanation, then maybe a PMR would be an idea...

Sincerely yours,
Alessandro

[cpalmer]

Alessandro, thank you again for you reply.

I have tried updating the rights to the user object and the rights of the group to which the user belongs.

There is only one group that has permissions to this application group.  The user is a member of this group.

The application group field is filter, string, length=9, and the Updatable field is checked.  There are no user exits.  Would it make a difference that the type is Filter instead of Index?  What would be the ramifications of changing it?  Would the changes apply to only new documents or would it change to everything already there?


Respectfully,
CJames

[Alessandro Perucchi]

Hi Cjames,

"index" or "filter" for a field has no influence about its "updateability".

So this is a simple field without any special role, just a string field...

I'm out of idea here, but maybe I will see something... would it be possible to do the following?

From the Admin Client, just do a "summarize" from the user, check the following options:

• User Permissions
• Groups
• Application Group permissions
• Folder permissions

Then do the same for the group that is assigned to this user, with the following options:

• Application Group permissions
• Folder permissions

and finally the same about the application group:

• Permissions
• Field Definition
• Field Information

And send them either to me personally or attach them to the forum. As you wish.

I will check if I find something there...

Sincerely yours,
Alessandro

[cpalmer]

Alessandro,

Thank you.  I have created the three logs.  I would prefer to send them to you directly, but can't find anywhere on the personal message for attachments.  How can I send them to you personally?

CJames

[cpalmer]

Please help!  This issue has not been resolved.  If anyone has any ideas, it would be most appreciated.

I'm not sure what additional information you would need, in addtion to what has already been listed in my original post.  I would be happy to answer any questions in an attempt to resolve this.

Thank you,
CJames

[wdssnyder]

Your application group permissions tab - highlight defined user and under document window is update checked on.

[cpalmer]

wdssnyder - thanks for replying.  Yes, update is checked on.  I've checked and rechecked the authorities that I'm able to grant using the OnDemand Administrator.  Is there someplace else that I'm not checking?  Another tool that I should be using?

[cpalmer]

Bottom line up front:  according to L3 support at IBM, "if a document has been federated, the metadata cannot be updated."  Ours is federated.  It would have been nice if that had been documented.  Our L2 support has pointed this out to their ID and they will add this limitation to the InfoCenter under 'arsdoc update'.

Their recommendation was that we "modify the table using native DB2 SQL statement."  Another new for me.  I will research how to do this.  If I can't find out how... I'll be back.   

Thanks to all who responded!
CJames

[mazhan2]

Hi James,

For my benefit, can you please explain what do you mean by a federated document.

Thanks,

NM

[MarkD]

For mazhan2, federating is sending the indexes fields to FileNet to manage the retention policy.  You will find the setting under the advanced option on the general tab for the application group.

Back to the topic.  I have the same situation as cpalmer, except I do NOT federate.  Field in the appgrp is updateable, I have update access to the appgrp and I am an admin.  Still fails.

[MarkD]

I'm all set with this, checked update annotation, instead of actual record.