Greetings Fellow Bricoleurs,
I started to look at [this patch][] from Greg to figure out just what
it fixes. And I realized that the problem comes about if a user edits
a story, and then leaves the story by some means other than the button
bar at the bottom of the story profile. Maybe he clicked "Save and
Stay" and then went directly to My Workspace, instead of clicking
"Save" or "Cancel". The result is that the story is not properly
cleared from the session. If he checks in the story with the stale
session still in place, it can (and clearly does) wreak havoc.
[this patch]: http://github.com/bricoleurs/bricolage/commit/7771128a6316e42b31230db345f4602e8aeb5662
The problem with the patch, however, is that it's either too broad an
application, or too specific, depending on how you look at it. It's
too broad in the sense that it might be a completely different story
in the session than the one that's being checked in. So no matter
what's checked in, the session is cleared. If there were unsaved
changes in the session copy and the user goes back into the story,
those changes will be lost.
On the other hand, perhaps a user who leaves the story profile
*should* lose any unsaved changes. After all, if they want to save
them, that's what the "Save" and "Save and Stay" buttons are for --
there are no guarantees documented anywhere that I'm aware of saying
that unsaved changes will persist. Indeed, it's already the case that
if you leave a story profile without saving changes and then edit a
different story, the changes to the first story will be lost, because
the second story replaces it in the session. It is in this sense that
the clearing of the cache in the desk checkin is too specific: we
should potentially clear the story cache as soon as the user leaves a
story profile, not just when he tries to check in a story.
So what to do? I suspect that there are other places where a stale
cache of a story causes problems, so it behooves us, I think, to
generalize the solution to remove the session copy of a story anytime
the user leave the story profile. I think that the way to do so is to
add a PreCallback that checks every single request to the server, and
if the profile key is not in the request but is in the session, we
remove it from the session.
Comments?
--David
I started to look at [this patch][] from Greg to figure out just what
it fixes. And I realized that the problem comes about if a user edits
a story, and then leaves the story by some means other than the button
bar at the bottom of the story profile. Maybe he clicked "Save and
Stay" and then went directly to My Workspace, instead of clicking
"Save" or "Cancel". The result is that the story is not properly
cleared from the session. If he checks in the story with the stale
session still in place, it can (and clearly does) wreak havoc.
[this patch]: http://github.com/bricoleurs/bricolage/commit/7771128a6316e42b31230db345f4602e8aeb5662
The problem with the patch, however, is that it's either too broad an
application, or too specific, depending on how you look at it. It's
too broad in the sense that it might be a completely different story
in the session than the one that's being checked in. So no matter
what's checked in, the session is cleared. If there were unsaved
changes in the session copy and the user goes back into the story,
those changes will be lost.
On the other hand, perhaps a user who leaves the story profile
*should* lose any unsaved changes. After all, if they want to save
them, that's what the "Save" and "Save and Stay" buttons are for --
there are no guarantees documented anywhere that I'm aware of saying
that unsaved changes will persist. Indeed, it's already the case that
if you leave a story profile without saving changes and then edit a
different story, the changes to the first story will be lost, because
the second story replaces it in the session. It is in this sense that
the clearing of the cache in the desk checkin is too specific: we
should potentially clear the story cache as soon as the user leaves a
story profile, not just when he tries to check in a story.
So what to do? I suspect that there are other places where a stale
cache of a story causes problems, so it behooves us, I think, to
generalize the solution to remove the session copy of a story anytime
the user leave the story profile. I think that the way to do so is to
add a PreCallback that checks every single request to the server, and
if the profile key is not in the request but is in the session, we
remove it from the session.
Comments?
--David
