Quick Edit Publish

Can an item to be published if it is in Quick Edit state?

I have an event content item and I have added a contacts content item to it through the slot. Both of them were approved and are pushed to public state. When I run the publishing routines, I see both items being published.

Now I changed my contacts item (moved it to quick edit) and approved it to become public again, basically creating a new version. I have changed the state of my events item to quick edit (not making any changes to the item but just changing the state).

when I run the publishing routines again, I see both contacts and event item being pubulished and my events item now shows the updated contacts item. I thought if an item is in quick edit state it will not be published.
But the event item is also being published and is now showing version 2 of contacts item on it and my understanding is events content item should not be published and should show version 1 of contacts item and not version 2.

Is this the normal behavior?

Regards
Ravi

Yes, it’s normal behavior

Items in quickedit state publish, but they publish the “last public revision” rather than the “current revision”.

In the case you describe the “included” or “child” document has been updated, it’s last public revision is now 2 instead of 1. This means that the new revision will show up on the site everywhere that the item appears.

The system makes sure that all of these updates are republished, even for pages that did not otherwise change.

Thanks Dave,

Is there anyway to stop items in quick edit state from being published? My goal here is not to publish event item which is in quick edit state until it has been manually approved by the user, thus showing revision 1 of contacts item rather than revision 2.

Regards
Ravi

I changed the quick edit setting from ignore to unpublish in the workflow. Still I see quick edit items being published. Should I be changing some other setting too?

You should not change the QuickEdit state to “unpublish”. All sorts of bad things will happen if you do that.

Again, what you are seeing is the system working as designed: you cannot prevent it from re-publishing an item because the included items have been updated.

Dave

Dave,

If thats the case, then could you please point me on how to solve our requirement?

When a child content item is modified, the owner content item’s workflow should be initiated and until and unless some one approves, owner content item should not be published, even if the child content item is published.

Should we look into itemfilters to get this to work or should we modify the jcr query to select all the content items to only include public and not quick edit?

Ravi,

If I understand what you are trying to do, Item filters won’t really help you.

You are concerned with child items which have returned to the public state, so filtering on “Quick Edit” isn’t going to exclude these items.

JCR Queries don’t operate on workflow state, so I don’t think that will be much use, either.

What we’ve done in the past is build notification for the parent item owners, but this requires customization, it cannot be done with just configuration.

Dave

Dave,

I am not really concerned about child items returning to public. I am more concerned about parent items not be allowed to republish until some one actually approves them?

Initially my plan was to build an extension which will change the state of the parent item from public to quick edit, whenever a child is modified. If the parent item owner is OK with the change, they would have to manually change the state from quick edit to public (as a means of approval). I initially thought this would work, as any items in quick edit state would not be published. If only that was that easy.

If not on child items, can I filter parent items on quick edit state and stop them from republishing, may be by adding another approval state between quick edit and publish ? If so, could you please point me towards proper direction?

You have mentioned notifications to parent item owners, would these notifications ask for approval from them or will they be just plain notifications describing about the change?

Also, could you please explain what are the implications, if quick edit state is changed from ignore to unpublish?

Regards
Ravi

Ravi,

The system was not designed to work this way. We made a conscious decision not to couple the revisions of included items to the approval of the parent item. Doing it that way makes content re-use very difficult: the new content appears only when the user edits or approves the parent item. If you make one small change deep in the web-site, it could take you a very long time to find and re-approve all of the pages that reference that item. It’s a logistical nightmare. So we chose to automatically include the most recently approved revision of each child content item whenever the parent item is rendered.

Adding more states won’t help. I think I’ve explained why, but the problem here is that we have an item (the child item) that has been approved and yet you don’t want it to be published.

You can use notifications to alert the owner of the parent item that it needs review, but this doesn’t ENFORCE that the owner takes action.

Changing Quick Edit to “Unpublish” will cause various pieces of content to mysteriously disappear if the publisher runs while the item is being edited. Remember that the publisher runs asynchronously with respect to the editing cycle.

Dave

Dave,

Thanks for the reply. As suggested by you, we are changing Quick Edit state back to Ignore from Unpublish…dont want to have disappearing content items.

For Public Item filter, I have changed the sys_filterbypublishableflag values from y,i to just y. This is causing the publisher not to pick up any items in Quick Edit state to Publish. With some little business process changes, I was able to get the required functionality to work.

Would you recommend changing sys_filterbypublishableflag values from y,i to just y for Public Item Filter?

Regards
Ravi