3

If you have a folder containing components that a user has only Read permission on, is it possible to roll your own authorisation logic in the event system so that you could allow a user to actually edit a component when they opened it?

So if you subscribe to LoadEventArgs and SaveEventArgs in the Initiated phase for a Component, do your custom authorisation and then update a Components ApplicableActions to include the Edit action, would that work?

comp.ApplicableActions.SetAction("Edit", true) 

UPDATE

I installed a small piece of event system code and set up a folder to give only the Read permission to a user:

private void ComponentLoad(Component subject, LoadEventArgs e, EventPhases phase)
{
    Logger.Write("ComponentLoad", subject.Id.ToString(), LoggingCategory.General);

    using (var elavated = new ElevatedPrivilegesScope(subject.Session, Privileges.SysAdmin))
    {
        Logger.Write("ComponentLoad ElevatedPrivilegesScope", subject.Id.ToString(), LoggingCategory.General);
        subject.ApplicableActions.SetAction("Edit", true);
    }
}

I can see that ComponentLoad gets hit quite a few times (which I've read before is to be expected) - but when the component is loaded, the GUI still shows a read-only interface, not en editable one.

Cheers

  • The first question would be why do they have only read only - when the intention is to allow them to edit? ... Perhaps you'll have to write your own 'version' of the GUI editor for that specific component type (assuming/hoping it's only the one)... then you could control access to that form (Tridion groups etc.) and edit as a specific impersonation user (perhaps keeping the 'real' editor in App data or a read-only field for audit purposes... messy. – Dylan .. Mark Saunders Jul 11 '18 at 14:26
  • I guess I'm just exploring alternatives to permissions on org items right now. A (contrived) example might be that a specific component is only editable on a certain day of the week (!). That day logic is trivial as part of an event system - but it appears to be difficult to use that result to make a specific component editable in the GUI (disregarding changing perms on its folder as this would affect all components in that folder as well). Or a scenario where everything is read only until a user assigns/starts a workflow activity - at which point they can edit until workflow is finished? – Neil Jul 11 '18 at 14:41
  • Have you inspected the XML representation of the Component? Does it reflect your Applicable Actions? – Rick Pannekoek Jul 13 '18 at 12:05
  • BTW: privilege elevation is not needed to set Applicable Actions (AFAIK). – Rick Pannekoek Jul 13 '18 at 12:06
  • Thanks Rick. The action was being set, but I realised the all I'm doing is assigning a custom action call "Edit", when what I want is the GUI to make a component that's read-only by permissions to be be editable in the GUI - the correct action I thin is "tcm:Edit" - but I can't set this via the SetAction method. – Neil Jul 16 '18 at 10:08
3

Rather than changing the Permissions on the Component/Folder, you could consider using the ElevatePrivileges and RestorePrivileges Core Service methods to elevate the user to a System Administrator during that session.

  • Hmmm - but would you do this from the event system though? – Neil Jul 11 '18 at 12:28
  • I've never actually done it, but I suspect so. Rick has a nicely detailed answer here that may help: tridion.stackexchange.com/a/17008/71 – Jonathan Williams Jul 11 '18 at 12:30
  • Hmmm - I cant find PrivilegeElevationScope or TransactionScope in the CHM .... I'll keep digging. – Neil Jul 11 '18 at 12:35
  • But there is a ElevatedPrivilegesScope class! – Neil Jul 11 '18 at 12:37
  • I found the ElevatePrivileges method on the ISessionAwareCoreService201603 interface. It looks, from the comments, that your user (the one you connect to the Core Service with) will need to be configured as an impersonation user too. I'm not clear on how you'd integrate this into your Events System code though. – Jonathan Williams Jul 11 '18 at 13:00
1

The Applicable Actions are not used to drive the authorization logic in the CM Kernel, but only to drive which actions are allowed/disallowed/disabled in the GUI.

So, an approach can be to use standard CM Security to restrict access in the most lax manner and then use a Load event handler to modify ApplicableActions so that the GUI can disallow actions even though CM Security would allow them.

UPDATE

I now see where your problem lies: indeed, to set whether the built-in Edit actions is allowed or disallowed, you would have to set the "tcm:Edit" Applicable Action, but the TOM.NET does not allow you to do this.

What will probably work is to change the Applicable Actions in a UI Data Extender.

On your comment: if you try to reverse it (allow actions in the GUI that CM Security will not allow), I think you are only complicating matters. You will still need a way to drive the allowed actions in the GUI, and you also need a way to bypass CM Security (e.g. using privilege elevation)

UPDATE 2

The restriction that so-called "system actions" cannot be changed in a TOM.NET event handler will be removed in SDL Tridion Sites 9.1

  • Rick I tried with a small piece of event code but found no difference in the GUI - see by update. – Neil Jul 12 '18 at 7:32
  • Rick - can you actually do the reverse, enable actions in the GUI - like tcm:Edit even though CM security/permissions would not allow "Write"? – Neil Jul 16 '18 at 12:49
  • Good to hear that this will be fixed in Sites 9.1! – Jan H Feb 21 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.