John: that suggestion would certainly have worked, but it
wound up being
unnecessary. What wound up happening was that the story was
automatically
assigned back to the only desk to which the user had write
permissions.
Typically this would have been transparent, but because the
user's corrupt
account caused so much load on the system just in trying to
access it, that
took about 20 minutes to happen. In the past, we used to
have a challenge
where stories would wind up being reassigned to the first
available desk, as
appeared alphabetically. THAT was confusing, but Kineticode
came to the
rescue.
David: you may have noticed in my original message that I'd
already
mentioned that all browsers experience the challenge.  I
anticipate you!
-----Original Message-----
From: john grumpet.net [mailto:johngrumpet.net]
Sent: Thursday, September 14, 2006 2:20 PM
To: userslists.bricolage.cc
Subject: RE: a way around user override?
On Thu, 14 Sep 2006, Joshua Edelstein wrote:
> The tail of the error log tells us this:
>
>
> [Thu Sep 14 16:37:13 2006] [info] [client 66.208.60.4]
(32)Broken pipe:
> client stopped connection before rwrite completed [Thu
Sep 14 16:40:14
2006]
> [error] [client 66.208.60.4] STORY "RFA
Vietnamese" forgot what workflow
it
> was in.
> Recent events for story "RFA Vietnamese":
> [Thu Sep 14 16:46:08 2006] [info] [client 66.208.60.4]
(104)Connection
reset
> by peer: client stopped connection before rwrite comple
ted [Thu Sep 14
> 16:46:08 2006] [info] [client 66.208.60.4]
(104)Connection reset by peer:
> client stopped connection before rflush comple ted
Try using the SOAP interface:
bric_soap workflow checkin story_foo
or some varient of this to get the story into some useful
workflow using
the credentials of of the busted user.
John
|