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

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

Comment
  • 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.

Children
No Data