[closed] Object status reverting back to "draft"

dckalorama · September 22, 2016, 8:55pm

I have a site running FarCry 6.2.7 and users who manage the content for a custom object claim that multiple items are reverting back to “draft” status when they had been approved. When they see this occur, they go into each item and re-approve the item. As they are re-approving the items, the remaining items revert back to “approved” status on their own. Any idea as to what might be causing this?

I checked the farLog table and can see no record of these items being sent to draft or that they were approved (other than the initial approval or when they were manually re-approved). Another curious thing is that I see farLog rows where the event fields has a value of “update” and the timestamp is within miliseconds of each other. There’s no rows to indicate the items were put into draft or that a draft versions were created. Plus, the users claim that they didn’t touch those items on the date the timestamp indicates. Also, I haven’t been able to recreate the actions that cause an “update” event row to be added to the farLog table. Any idea, how “update” events are added?

justincarter · September 23, 2016, 6:14am

The “update” event for farLog happens in setData() in farcry.core.packages.types.types which is the component that every content type extends:

github.com

farcrycore/core/blob/master/packages/types/types.cfc#L359


			<!--- set friendly url for content item. --->
			<!--- TODO: Checking for application.fc so that it is ignored on Install. This needs to be more eloquent --->	
			<cfif isDefined("application.fc.factory.farFU")>
				<cfset stresult_friendly = application.fc.factory.farFU.setSystemFU(objectID="#arguments.stProperties.objectid#", typename="#arguments.stProperties.typename#") />
			</cfif>
			
		</cfif>
		
		<!--- log update --->
		<cfif not arguments.bSessionOnly AND arguments.bAudit>
			<farcry:logevent object="#arguments.stProperties.objectid#" type="types" event="update" notes="#arguments.auditNote#" />
		</cfif>
		
		<!--- Announce the save event to listeners --->
		<cfset application.fc.lib.events.announce(	component = "fcTypes", eventName = "saved",
													typename = arguments.stProperties.typename,
													oType = this,
													stProperties = arguments.stProperties,
													user = arguments.user,
													auditNote = arguments.auditNote,
													bSessionOnly = arguments.bSessionOnly,

So if the users are using the webtop to save objects then this code should always run and the records should show up in the farLog table.

For the farLog entries that have the same data within milliseconds of each other, is it possible that the user might be double-clicking a “Save” button somewhere? (FarCry usually disables the Save button after the first click, but maybe there is a case where that is not happening?).
If an object is sent to draft/approved then I think there should be a log entry for it “todraft”/“toapproved”. I don’t know of a way that the objects could be changing by themselves, unless two people are somehow editing the object at the same time (usually Object Locking prevents this) and then one person saved a draft object just after the other person approved the same object? Is that possible?
Is the site running on a single server? Or do you have multiple servers with a load balanced configuration? For load balanced scenarios you would need to use a caching server such as Memcached so that the cache is shared between servers / instances.
Do you know if they are on a corporate network which has a proxy server configured for their browsers? Sometimes it’s possible that a misconfigured proxy server will cache a page response that shouldn’t really be cached.

Hope that helps!

dckalorama · October 11, 2016, 3:41pm

We got further clarification from the users and finally, narrowed down the problem to an array field that allows the users to select related items of the same type. The attribute bSyncStatus was set to “true”, so when one item was put into “draft”, the related items would also get sent to “draft”. It also seemed that items related to the related items would also go into draft. None of this is recorded in the farLog table. Just publishing one item would re-publish the many items previously put into draft status. Setting bSyncStatus to “false” fixed the issue.

justincarter · October 11, 2016, 11:44pm

Thanks for persisting with the issue, it sounds like bSyncStatus might be doing something outside of the normal status / approval mechanisms and needs to have appropriate logging in place so that this could have been picked up on more easily!

We could probably consider a change or improvement to bSyncStatus – sending related items back to “draft” might not have been it’s original intent. It’s often most useful for sending dmFiles to “approved”, because “draft” files typically aren’t published / publicly available. We could either stop it from sending related items to draft, or we could make it configurable so that for each array/uuid property the developer can choose which statuses bSyncStatus could apply (e.g. only draft->approved).

Do you have any thoughts on that or are you happy with setting bSyncStatus to false for now?

modius · October 12, 2016, 1:55am

I think the default behaviour should only be DRAFT >> APPROVED for related items. Onced something has been published, the is out of the and folks should be forced to send related content back to DRAFT manually.

Another significant improvement would be indicating the related content’s status in the content type’s default librarySelected.cfm view.

dckalorama · October 18, 2016, 4:06pm

I think logging would definitely help, since FC Webtop users can view the approval histor. I think now knowing how bSyncStatus is applied, it’s easy to just set it to “false”. Is it “false” by default?

I just ran into a case on a different site where items were getting “ghost” approved. For example, a Case Study was assigned to a Staff Bio. At the time the Case Study had an “approved” status. The Staff Bio was approved but then at a later date the Case Study, was un-published/set to “draft” status, but still assigned to the Staff Bio. At an even later date, a webtop user makes a change to the Staff Bio, approves it. Upon approval, the Case Study gets “ghost” approved.

In this scenario, would it be possible to stop the related draft item from getting inadvertently re-approved? Anyhow, setting bSyncStatus to “false” is fine.