16

I have been looking into this for a couple of days now and have not found anything. The problem is we have people that were publishing out content that should not have been released. We went to the publishing queue to see what transactions would have caused the content to be published, but what we found was that users found out they could delete the transactions from the publishing queue.

We were able to find the transactions that caused this problem in the database, but since it was gone from the publishing queue, we had now way to trace it back to an individual using their "trustee Id", at least no way that we could think of.

So is there a way to restrict users from deleting the transactions from the publishing queue?

Improve this question
2
  • Tim, which Tridion version are you using?
    – Jan H
    Commented Mar 1, 2013 at 23:55
  • Hi Tim, if one of the answers below helped fix your issue, could you consider accepting it? (click the check mark next to that answer)
    – Bart Koopman
    Commented Mar 4, 2013 at 12:15

4 Answers 4

Reset to default
12

As always, there's multiple ways to skin this cat...

  • You could always write an event that would catch the DELETE action on a PublishTransaction object and cancel it - though this may have other repercussions I have not researched (will the purge tool still work for instance)
  • You could disable the delete button for non-Admins via a GUI extension as mentioned by Chris
  • You could implement a different level of audit logging for these actions

I would suggest looking at a solution like the one created here. Though it is in its very infancy, the event system + logging part is working really great, and it is writing all events to a mongodb database that you can use to query and write whatever reports you need.

Improve this answer
1
  • Thanks everyone for the quick answers. I think my best bet is to write an event that logs only when a transaction is deleted. That way I could still have a record of it, but all the main functionality is still in place.
    – Tim P
    Commented Mar 4, 2013 at 14:32
13

The publishing queue is designed to be a queue, not a logging mechanism. Restricting users from deleting publish transactions has it's disadvantages. I.e. it refrains users from deleting big transactions in a busy publishing queue.

Why not implement an alternative logging on who published what at what time? This could be done with an event system by subscribing asynchronously to the PublishTransaction (Save event type and TransactionCommitted phase). With this event system subscription you can log the item which is published, and the user who published it.

To answer your question. The users either have the right to publish and manage the publish queue or not, it's not very fine grained. You could use the event system to stop the deletion of the publish transaction for certain users, but this would trhow an error message to the user, instead of restricting the delete rights itself. You could also do a GUI hack to disable the delete option on the publish transaction, but this would be an unsupported hack, also this would remove a standard feature, very confusing. So I would not advise to restrict the right to delete publish transactions.

Improve this answer
3
  • 1
    This is a great answer, although I would argue that you cold create a supported GUI extension (assuming you are using 2011 or higher) which disables the delete button if the user is not an admin. I have built a number of publishing loggers in the past, and suggest that as the way to go.
    – Chris Summers
    Commented Mar 1, 2013 at 23:01
  • 1
    Thanks. I can't remember where I read/heard this -maybe it was the Tridion Talk (shamelessly plugging a great initative)- which mentioned we should not change the standard behaviour of the GUI but only add additional functionalities to it. Changing the standard behaviour like disabling or removing the unpublish button is confusing for the user, it is unexpected and they don't know why they cannot use this feature. Makes sense I think so let's apply this kind of GUI extension with care.
    – Jan H
    Commented Mar 2, 2013 at 0:00
  • Technically, the actual extensions customers write are not "supported" (regardless if they add or remove functionality); however, the mechanism to create extensions is supported. There's probably a balance between changing the behavior, documenting it, and hinting to the user why they can't do certain things. Did I mention documenting it? :-) Following Jan's recommendations, an alternative to removing the delete button is to offer a different custom publishing queue. It might just be worth limiting who can publish though.
    – Alvin Reyes
    Commented Mar 2, 2013 at 5:17
4

When content is checked in it is basically considered eligible for publishing. Especially when it involves an update to existing content that already has been published to the web site before. When you publish content Tridion may publish also content that relates to the content being published. This can easily lead to content being published implicitly that should not have been released yet.

Consider implementing workflow so content has to be approved explicitly before it is released to be published to a certain publication target.

Improve this answer
1
  • +1 and thanks for answering, Jeroen. This does solve the first problem of restricting what content gets published.
    – Alvin Reyes
    Commented Mar 2, 2013 at 5:18
2

Sounds like there are two problems:

  1. preventing users from publishing content that shouldn't be published
  2. blaming the correct individuals when it happens (i.e. "Tridion forensics")

Related possibilities include link resolving or the queue automatically being purged.

Blame The Default Resolving Behavior? (aka Link Propagation)

When publishing an item, all items that use it are re-published along with any binaries the templates publish. Sometimes authors don't realize what they're (re)publishing when selecting what they think is one item. Show Items to Publish will show these when queuing up items.

Or the Purging Configuration

The queue is regularly purged (requires login) based on the CM configuration. Authors can definitely cancel their own publish transaction (unless done by an administrator) and apparently delete old transactions.

Maybe Fix the Need to Hide?

If users are attempting to hide their publishing reuqests, consider some other options.

  • If releasing the wrong content is important (e.g. financial data, sensitive content, or anything that increases liability) consider workflow and more governance.
  • Use authorization to effectively hide sensitive components and pages from certain users.
  • If you're okay with the occasional mistake, encourage authors to know how to quickly fix them and/or have regular reviews.

You can find a way to prevent and track having the wrong content published and if really needed, check IIS logs to check time stamps, publishing activity, and IP addresses.

If users get into significant trouble for mistakes, they may be less likely to use the CMS.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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