Category attribute update content server 21.4

Seejeys

Hello.

The user is not allowed to change the attribute category.

How to change the category from user if only Admin is allowed to change. Using sub tug or webreport?

I.e. admin on behalf of username.

Ll_reptag_6788866 Rinswr:userid:12345. Is not working, access denied

Alfonso Scoppetta

Hi, if you have the Module Suite, you can create a content script that updates the category as Admin.

Content Script supports the execution of a script impersonating specific users.

This configuration applies for both:

• scripts explicitly executed by users
• scripts executed by the system (scheduled, workflow steps, callbacks, etc…)

The “Run As” configuration panel is accessible within the Specific > Advanced Settings tab or from the Content Script Editor in the Administration tab (if visible).

In order to be able to perform a “Run As” configuration, a user must have impersonation privileges.

Be careful, though, because in this case, the audit will show that the action was performed by the admin, and there will be no evidence of who actually requested the category update. For this reason, at AnswerConsulting, we usually create our own custom audit to have a proper record of everything.

In any case, here’s how you can update the category value in a content script with just a few lines of code

I hope it was helpful!
Let me know

Best regards
AS

appuq

in WR or before that you should check if using a SA account(Admin is a user who has SA, any user can be made SA) you can change category data on a Document or folder. If so you can create a WR as a SA and say impersonate the call.

Seejeys

We need this entry to see in the audit which user made the change, and not the administrator

Jacopo

Hi,

this is what @Alfonso Scoppetta was previously referring to

"Be careful, though, because in this case, the audit will show that the action was performed by the admin, and there will be no evidence of who actually requested the category update. For this reason, at AnswerConsulting, we usually create our own custom audit to have a proper record of everything."

We usually create our own audit events and then quickly create a views that provide users with the full spectrum of audit on these nodes: the out of the box and the custom one.

In the image below, you can see it in a component on the right, and as you can tell, almost all the events are custom, enriched with visual and contextual information

In the second screenshot, you see it in the middle, within another perspective

In the third, it’s in a context similar to the first one, on the right.

Many of these events are generated by impersonating the administrator for technical reasons, which is why creating custom audit events tied to the out-of-the-box events can help recreate the correct history.

I’ve seen consultants in the past modify the user associated with audit events directly in the database, and I strongly advise against it. Not only is it a bad practice, but it would also void the client’s warranty on the product, stop maintenance, and likely jeopardize your partnership with OpenText.

Jacopo Malnati

Seejeys

I see the solution in the moment to give rights to edit the category and immediately take it away.

Start webreport

Give modify right

Edit catacation tag

Take it away right

End webreport

Greg Griffiths

be careful with escalation of access as it there is an issue and you dont revoke it, then the user retains the higher access which may be an issue for some customers.

Jacopo

https://forums.opentext.com/forums/developer/discussion/comment/969790#Comment_969790

Not to mention race conditions and the potential for fraudulent exploitation with enough effort. I'm also reasonably sure that it wouldn't pass a security audit. From my perspective, uncontrolled escalation of access should never be the solution.