[PUBLISHING-303] Investigate & POC. How the campaign publishing works Created: 12/Jul/16  Updated: 19/Dec/23

Status: Accepted
Project: Publishing
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Spike Priority: Neutral
Reporter: Laura Delnevo Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: usability, ux-improvement-selected
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:
Epic Link: Publishing Page related content
Team: AuthorX

 Description   

As an author, when publishing a page I want all related assets to be published with the page, in one click, so I can update new content and its related assets fast

 

  • Investigate How campaign publishing works to publish content in one go using the existing workflow
  • Create a PoC to publish a page's related assets with the page publication, in one click 

 



 Comments   
Comment by Antti Hietala [ 12/Jul/16 ]

Concerns raised by had:

  • Should all the dependencies be pulled in or not?
  • Approval process. How do we display dependent items? Is it possible to reject one item during publishing or is it necessary to reject everything? Who is responsible for rejected dependent content? Author of the page that pulled it in? Or author/editor of the dependent content?
  • What about unpublishing content?
  • How does it work with publishing - is it all in one transaction?
Comment by Richard Unger [ 12/Dec/18 ]

There are many more concerns for implementing this:

  • What if parent content of a dependent item is not published? Publish that too?
  • What if you don't have permission (normally) to publish the dependent item?
  • Current publication commands work on a single workspace, dependent items can come from many workspaces.
  • How to handle an error with a single dependent item?
  • Publish yellow items, or just red?
  • Allow timed publication in this scenario?
  • Complicated cases: what if an ancestor of a dependent item has been moved on author system, but not yet on public?
  • What about the dependencies of the dependencies?
  • How to display all this to the user in an understandable way?

 

We've had to implement this functionality for a customer. It wasn't pretty. We restricted it to publishing DAM dependencies, in order to avoid dealing with the transitive dependencies. We publish unpublished parent folders along with the dependent items if needed. We display all the dependencies in a dialog, and allow the user to choose which ones should be published via checkboxes.

If you ever implement this, and you're interested, we can give you a demo and talk about it.

Generated at Mon Feb 12 10:37:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.