[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bricolage-devel
Subject:    Re: Bricolage State Errors
From:       "David E. Wheeler" <david () kineticode ! com>
Date:       2008-10-30 0:21:46
Message-ID: 8636139C-7800-486A-8670-11A409792214 () kineticode ! com
[Download RAW message or body]

On Oct 29, 2008, at 16:37, Bret Dawson wrote:

> Specifically, there's an element called "lineup manipulator" that
> producers can add to news stories. When a news story is published
> containing a lineup manipulator, lineup_manipulator.mc edits one or  
> more
> covers to add the news story as a related story.

I try to avoid hacks like this. Better is to have the covers look for  
all stories with linup manipulator subelements and to list them,  
without any element-level relationships.

> The code select that the lineup manipulator element offers to the
> producer looks at the checkin/checkout state of the covers, and only
> offers to edit those covers if they're not checked out.

That's good.

> But if somebody checks out one of those covers in between the time  
> when
> the code select is displayed and the time the story is published and
> lineup_manipulator.mc runs, the state of the cover can get very wobbly
> indeed.

The code select should double-check that the story in question has not  
become checked-out.

> When this happends, attempting to edit that cover directly throws an
> error, because (according to the error message) something in Bricolage
> can't call "get_desk" on an undefined value.

Yeah, the code callback probably mucks up the checkout state.

> It's possible to check the cover out, although the error displays on
> checkout, and it's also possible to check it back in and move it from
> desk to desk and even to republish it, but not to edit it, because
> Bricolage throws the error instead of displaying the story profile.
>
> It does seem possible to resolve the situation by having a different
> user (one who did not see the error in the UI) check it out and  
> publish
> it. Somehow, the poison seems to be associated with a user, and having
> another user come to the rescue fixes the problem. The new user  
> doesn't
> ever see the error.

Bleh.

> Anyway. It's a tough thing to reproduce, because of all the timing
> involved. But I'll keep y'all posted.

Thanks.

Best,

David

[prev in list] [next in list] [prev in thread] [next in thread]