Under Community Review

Hello guys,

Could you please share a use cases you want from this feature?

Would you like to preserve "Failed" publish transactions? What a use case to preserve it?

For how long you want data to be preserved? Should it be configurable automatic action or require manual trigger?

In general what are a use cases to have historical data in publish queue?

Would you like as well to know what version of the item was published? Was it published from workflow or by user?

Permanent Publish Data

Do not allow items to be deleted from the Publish Queue.  Sometimes in Production, content has been incorrectly published or unpublished, and the user is able to remove the history and we have no idea who published what, or when.

Suggestion is to have the publish data be permanent....we could maybe archive it, but never delete it....

Robert Curlette
Parents

  • The argument against this has always been that an endlessly growing publish queue would lead to performance problems, and of course, that you can use the events system to take care of your audit-trail and similar needs. All well and good, but this would definitely be an enhancement to have it in the product. So sure - it would require architectural changes to do it well, but that needn't be a bad thing. Imagine if at the same time, maintenance tasks like purging the publish queue could be eliminated. What other aspects of related functionality should be included?

  • in reply to Dominic Cronin

    Indeed Dom. Allow configuration of a specific 'historic publish transactions database'
    Tied with above, the ongoing publish transactions (say, last {configurable} 7 days) are in a specific db/table that the publish queue interacts with on a daily basis.
    Granular purging options (historic transactions for items - leaving the last transaction for any published item - puts it to the current state)

  • in reply to Mark Saunders

    A 'starter' set of reports; most published item

Comment Children
No Data