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
  • in reply to Mark Saunders

    I think it's been covered before but:

    Some clients need to know what version of a specific piece of content was on the site at a specific time. Currently we have to develop involved pieces to provide this ability. If we could confirm when a specific version was published that would be sufficient evidence and we could do away with complicated front-end/back-end solutions.

    Who published the item, or the process that triggered it would certainly be useful.

    Failed items would be good from a reporting perspective (reviewing publishing capablities in general: frequent failing pages/times/content types etc.).

    From my use cases, this data would need to be available for considerable time, thus it's likely it would result in a very large body of content. Given it's 'historical' reporting value an not really intended for CME use - it would useful to have a storage strategy such that this content could be purged out of the CMS into a stand-alone set of data for example.

  • in reply to Mark Saunders

    I think it's been covered before but:

  • 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?

  • in reply to Dominic Cronin

    Hating that "enter" posts!!! please delete my other responses!!!

    • Indeed Dom.
    • Allow configuration of a specific 'historic publish transactions database'
    • Tied with above, the ongoing publish transactions (say, the 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)
    • A 'starter' set of reports;
      • most frequently published items
      • average publish time (starts to become possible/relevant if we have all publishing data {for items based on a specific schema, template, etc.)
      • average batch size of publishing
      • something to indicate to use the implications of publishing DCPs (average items in transactions for example)

  • in reply to Mark Saunders

    A 'starter' set of reports; most published item