Bricolage Bricolage → 1.10.10

Comments and changes to this ticket

• 

  theory November 3rd, 2009 @ 12:12 AM

  • → Assigned user changed from “theory” to “beaudet”

  I suspect this bit of configuration:

  # Workflow desk permission enforcement.  By default, a non-administrative user's
  # permissions on an asset are determined by taking the highest permission available on
  # any permissionable aspect of the asset (category, element type, etc.),
  # including permissions on the assets current desk within a workflow. A side
  # effect of this highly trusting and collaborative approach is that a user can
  # search for and edit an asset with the "Find" feature even though the user has
  # no permission to the assets current desk. Some customers might prefer to enforce 
  # the workflow permissions separately from asset permissions, thereby taking the 
  # LESSER of the highest permission allowed by the asset and the hightest
  
  # permission allowed by the desk in the assets current workflow.  This provides an 
  # effective way to 'protect' an asset once it reaches a certain desk.
  # To enable this feature, set this directive to "Yes", "On", or "1".
  
  ENFORCE_DESK_PERMS_DISTINCTLY = Yes
  

  That's not in core, likely from a patch from David. I see no other things in his configuration that seem likely to effect stories and their desks. So I bat this one back at him.

  —Theory

• 

  theory January 19th, 2010 @ 09:33 PM

  • → Milestone changed from “1.10.8” to “1.10.9”

  David, any chance you could have a look at this issue this week? I want to get 2.0 out next month.

  Thanks!

  David

• 

  theory January 29th, 2010 @ 12:08 AM

  • → Milestone changed from “1.10.9” to “1.10.10”
• 

  theory February 18th, 2010 @ 06:47 PM

  Just heard from David Beaudet, who won't be able to get to this issue this month. I'm leaving it open for now, though, for when he can get to it.

• 

  Aaron Fuleki February 19th, 2010 @ 04:17 PM

  Here are the STR for a case that we see on 1.10.9. I'm not sure if it's the same bug or not.

  1) User A checks out a cover story that lists all the staff biography stories in their department.

  2) User B checks out their own biography story, updates it, and checks it in to publish.

  3) The biography story template builds a list of all published cover stories that list the current biography story, and calls publish_another on all the currently published versions. This creates a publish job for the cover story in User A's workspace.

  4) User A's cover story is successfully republished, showing User B's changes.

  5) User A logs back into Bricolage, and continues editing the checked out version of the cover story. When they click the "Edit" link, Bricolage complains that the story has forgotten what workflow and desk it was on, so they've been reassigned.

  The complete error log entry:

  ---

  [Fri Feb 19 15:57:30 2010] [error] [client xxx.xxx.xxx.xxx] STORY "ITS Staff" forgot what workflow it was in. Recent events for story "ITS Staff":

  2009-05-14 14:36:49: Category Added to Story by user1

  2009-05-14 14:36:49: Story Moved into Workflow by user1

  2009-05-14 14:36:49: Story Moved to Desk by user1

  2009-05-14 14:36:49: Story Created by user1

  2009-05-14 14:36:49: Story Changes Saved by user1

  2009-05-14 14:36:56: Story Changes Saved by user1

  2009-05-14 14:38:23: Story Changes Saved by user1

  2009-05-14 14:39:03: Story Changes Saved by user1

  2009-05-14 15:47:41: Story Checked In by user1

  2009-05-14 15:47:41: Story Removed from Workflow by user1

  2009-05-14 15:47:41: Story Changes Saved by user1

  2009-05-14 15:47:44: Story Published by bricolage

  2009-06-05 09:16:52: Story Moved into Workflow by user2

  2009-06-05 09:16:52: Story Checked Out by user2

  2009-06-05 09:16:52: Story Moved to Desk by user2

  2009-06-05 09:37:50: Story Checked In by user2

  2009-06-05 09:37:50: Story Removed from Workflow by user2

  2009-06-05 09:37:50: Story Changes Saved by user2

  2009-06-05 09:37:53: Story Republished by bricolage

  2009-08-03 09:30:34: Story Moved into Workflow by user

  [Fri Feb 19 15:57:30 2010] [error] [client xxx.xxx.xxx.xxx] STORY "ITS Staff" forgot what desk it was on.

  ---

  Also note that the log entries it claims are "recent events" are actually all dirt old; it's looking at the oldest ones first. It seems to me that they should be in reverse chronological order. Is that another bug?

• 

  theory February 23rd, 2010 @ 10:23 PM

  • → Assigned user changed from “beaudet” to “theory”

  Thanks or the STR, Aaron, very much appreciated.

  Okay, so here's the deal. For hysterical reasons, the publish() method of Bric::Util::Burner removes a document from its workflow and desk after it's done publishing it. I don't think that's the right place for that any longer, so I'm removing it. It's now the responsibility of the code that does the publishing (or schedules the publishing job). Once the publish is scheduled, the doc should be removed from workflow, not after it is actually published, which might be some time in the future.

  The UI already works this way. Users can't republish a story that's currently checked-out, and if it has been changed since the last publish, only the new version can be published, not the existing version. This is actually a bit surprising to me, and I'm amazed no one has complained. But it is safe, and when you do publish from the UI, it does remove the document from workflow and the desk, with no need for Bric::Util::Burner to do it.

  Bric::SOAP::Workflow, OTOH, was not removing documents from workflow after scheduling their publish. It clearly needs to do that, but only if it's a new publish, not a republish. So I've updated that code to do its thing too.

  Committing now. Aaron, I'd appreciate it if you could apply the patch to your install and let me know if you have any problems.

• 

  Bugs (at bricolage) February 23rd, 2010 @ 10:29 PM

  • → State changed from “new” to “resolved”

  (from [a53affd135f292f7b27433a8fbe4eb9ee3648428]) Fix workflow forgetting bug.

  Bric::Util::Burner's publish() method no longer removes documents from workflow after publishing them, as such is the responsbility of the code that calls publish. The publish callback already did, and now so does the Bric::SOAP::Workflow publish() method. Thanks to David Beaudet for the report and Aaron Fuleki for the steps to replicate [#98 state:resolved].
  http://github.com/bricoleurs/bricolage/commit/a53affd135f292f7b2743...

• 

  theory February 23rd, 2010 @ 10:37 PM

  • → State changed from “resolved” to “open”
• 

  theory February 23rd, 2010 @ 10:38 PM

  • → State changed from “open” to “resolved”
• 

  Michael Herring March 25th, 2010 @ 07:46 PM

  David,

  I applied the patch this morning to our 1.10.9 instance and it resolved the problem. Thanks.

• 

  theory March 25th, 2010 @ 09:15 PM

  Great, thanks for letting me know, Michael.

  Best,

  David