5

In order to keep people from accidentally editing/republishing a page, is there a way to lock it down for a period of time?

Additional info: For business reasons, there are certain pages that need to be 'frozen' with no updates/publishing allowed. This would include any object dependencies(templates, components, etc). Currently, I don't know of any way to keep users from accidentally changing a dependency(or even the object).

1
  • If editing isn't allowed, why do you also need to prevent republishing? – Dominic Cronin Nov 23 '14 at 19:17
6

The simplest option is to check the page out. Then others cannot change it (and any publish actions will result in the last checked in version being published).

However keep in mind that components used on that page could be changed independently. To solve that issue you will need to lock (checkout) every dependency of the page.

You might consider a workflow process to manage this for you.

3

Could you provide a bit more detail about the reason for this, please?

If this is content that has to remain 'stable' for regulatory or business critical reasons, and you only want certain Groups of users to be able to update this content, then could implement this requirement using the Tridion Workflow or the Tridion Security Model (as suggested by @Hiren).

However, before embarking on this, you should ensure that you have captured the full requirements and constraints around this functionality. For example:

  • What Groups of users can update the content initially?
  • Who would need to approve any 'overrides' to the content freeze?
  • Does this just apply to a single Page/Component, or is it a collection of items?
  • Is there a set time that the freeze needs to remain in place, or is this 'ad-hoc'?
  • etc.

Hopefully the full requirements & constraints should guide you to a possible solution(s) (or you can post them here and the community can help).

1
  • 1
    I would definitely go for a workflow lock on pages & components that need locking. Then dissolve/cancel the workflow when not needed anymore – Nuno Linhares Nov 19 '14 at 14:38
1

It will be helpful if you provide more information so that we can suggest right approach.

There are two options that I can think of for this:

  1. Remove permission from the structured group for the specified time for that particular user so that pages inside it can't be edited or published. This can be cumbersome if you have lots of such requests, you can automate some part of it.
  2. Use event system to monitor the save and publish transaction, cancel save or abort publish transaction for those pages based on the criteria which can be defined in a component.
1

I would suggest to use a Bundle to group the items related to the locked page, possibly with the name of the Page in the Bundle name.

Then you could use a small GUI Extension / .Net Custom Page to make it a bit friendlier for users. For example, a 'Lock Page' option that will:

  • Create a Bundle
  • Checkout the Page, add it to the Bundle
  • Checkout all Components used on the Page
  • Consider also 'locking' the Components linked to Components on the Page, but this could result in a waterfall of lots of locked Components. However, you would see them in the Bundle...
  • Implement an 'Unlock' item that would be only available on a Bundle item type (GUI Extension) and would Checkin every item in the Bundle. This is optional - it would also be easy to select everything in the Bundle and go to Versioning, Checkin and have the same result as a GUI Extension.
1

Additional info: For business reasons, there are certain pages that need to be 'frozen' with no updates/publishing allowed. This would include any object dependencies(templates, components, etc). Currently, I don't know of any way to keep users from accidentally changing a dependency(or even the object).

Workflow will not help you here because you can still publish a page in workflow (it will just publish the previous non-workflow version). There is no feature in Tridion security which allows you to prevent a single page from being published to a target (other than disallowing all publishing to that target or removing all access rights from the page; even then it might show up in resolve operations from the parent SG, components on it, etc).

If you want to go even further you might also want to prevent images that are displayed on the page from being changed (which is even harder because they are not independently rendered).

Considering the scope of the requirement (absolutely no changes must be made to a published item) I would consider implementing this as a deployer extension (so you lock your published pages and any binaries displayed on the page at the deployment side returning an error to the content management side stating items are locked for business reasons and are not allowed to be modified).

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.