Sign up for our Cascade Server Weekly Webinar icon Hannon Hill Logo
Forum | Best Practices | Idea Exchange | Blog | FAQs | Sitemap | Success Home
Notification-off Favorite-off

Don't Allow Publish Dupes

6 Thumb-up Thumb-down
Idea by irifkin about 1 month ago - Open

Although I continue to tell my Web editors not to keep clicking publish and to view the queue, some of them repeatedly publish the same assets because they don’t see the change on their website. I suggest showing the user an error message that says something like: This asset was just published by you and is still in the publish queue.

I’m not sure if it should allow them to publish it again or make them wait. Or maybe they’ll need to cancel the previous publish job.

All I know is that I hate seeing a dozen publish jobs for the same folder, slowing down publishing for everyone.

7 comments

  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 month ago Permalink

    Would it possible to give these users the ability to cancel publish jobs (Role Abilities) and teach them to cancel the duplicate jobs in the interim?

  • 0 points Thumb-up Thumb-down Favorite-off by irifkin about 1 month ago Permalink

    Giving the users the ability to cancel their own jobs doesn’t help
    — why would they learn to cancel if they aren’t all learning to not
    publish repeatedly.


    Giving everyone the ability to cancel everyone’s
    publish jobs would solve some issues surrounding this problem, but
    would most likely introduce new concerns. For example how would one Web editor know if a site being published twice is a duplicate or going to different destinations?

  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 month ago Permalink

    So is their rationale that if they keep hitting publish the job in the publish queue already will go faster? Are they expecting it to have some other effect beyond just creating yet another publish job?


    Or do they not have access to the publish queue at all and don’t know that it hasn’t been published yet?

  • 0 points Thumb-up Thumb-down Favorite-off by DaveW about 1 month ago Permalink

    They don’t understand, even when previously instructed, that publishing is not instantaneous and is serial not parallel.  They don’t think that someone could be publishing a folder with 1000 items before them, and it could take their job 20 minutes to be even addressed.  Thus, they hit publish again, again, and again. 

  • 0 points Thumb-up Thumb-down Favorite-off by irifkin about 1 month ago Permalink

    Thanks DaveW. That’s it exactly.

    They have access to the publish queue and I have been instructing them to use it. It’s just hard to get all 500 Web editors to listen and remember.

  • 0 points Thumb-up Thumb-down Favorite-off by len.lanphar about 1 month ago Permalink

    From the user perspective, they hit publish and for some reason the content isn’t showing up on their site. If they don’t know (or don’t remember) to check the publish queue, they will likely have theories such as “maybe I meant to hit the publish button but forgot, or maybe something didn’t ‘take’.” This leads to hitting publish again.

    Another use case where this turns up is the user submits something to the publish queue, and then after they submit they notice a typo on a page, so they fix the typo and republish. If the first job is still pending, there are now 2 of the same job in the queue.

  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 month ago Permalink

    Ok, that makes sense. I think it’s probably a good rule to not allow a job to be placed in the queue while the exact same job is already in the queue ahead of it.

Sign in
© 2001-2009 Hannon Hill Corporation. All rights reserved.
Accessibility | Legal | Technical Support | Knowledge Base | Site Map | Index
Valid XHTML 1.0