Here's a little utility I lib'ized for my own templates
that
consolidates some of the more commonly used parameters I use
when
calling story list() method. Maybe this will help?
sub listStoryAssets {
my ($hash, $burner) =  _;
# figure out whether we're publishing or previewing
my $mode = $burner->get_mode;
$hash-> = 1
if $mode == Bric::Util::Burner::PUBLISH_MODE;
$hash-> = 1
if $mode ==Bric::Util::Burner::PUBLISH_MODE;
$hash-> = 1;
return
Bric::Biz::Asset::Business::Story->list($hash);
}
> Furthermore, it appears that published_version=>1
may only work
> when used by publish_another. Can anyone confirm if
that is the case?
I don't believe that is the case because the list() method
behavior
operates completely independently of the Burner -- and the
list of
stories you retrieve are discrete story instances, even if
the version
number is the same -- if you use the checked_in parameter
above, you
shouldn't get the publishing problem you mention below --
list() will
return the instance prior to the instance that is created at
check out.
-----Original Message-----
From: Matt Rolf [mailto:rolfmdenison.edu]
Sent: Wednesday, June 06, 2007 10:20 AM
To: userslists.bricolage.cc
Cc: Faith Bazley
Subject: Deleting links when expiring stories
The following is an e-mail from one of our students working
on the
CMS that she wanted to send to the message board. I'm
including it
here so others can respond, and also wanted to ask if there
was an
issue with new people subscribing to the mailing list. We've
had two
students try to subscribe and they have been unable to.
Thanks,
Matt
On Jun 6, 2007, at 10:04 AM, bazleyfdenison.edu wrote:
> I have designed a template that deletes related links
from stories
> when the story that the link goes to is deleted. It
calls $burner-
> >publish($story, 'story', $user_id, '') to republish
the story
> after the link is deleted. But there's a problem when a
user has
> this story checked out at the time the template is
called. When the
> template executes, the story is changed, but then the
story is
> automatically published despite the fact that the user
may have
> made other changes that were not meant to be published
yet. An
> error then returns that the story doesn't have a
workflow because
> it was moved upon publishing, just like the problem
reported here:
> http://marc.info/?l=bricolage-general&m=1
15946749314263&w=2
>
> I had originally written the template to make the
changes on the
> pages, then check to see if the story is on a workflow,
and only
> publish if it is not on a workflow. We then ran into
the problem of
> users leaving pages sit on workflows for too long,
causing the
> broken links to remain on the site even though they
were taken off
> the pages.
>
> To overcome this workflow error, David suggested to use
the
> parameter published_version => 1 when looking up
stories in the
> template. However when this is done it seems that the
published
> version is the same as a checked out version because a
new version
> is not created until a story is checked IN. So if I
tell the burner
> to only publish stories of published_version=>1 and
the user has
> that story checked out, the checked out version is the
same as the
> published version and we run into workflow error above.
> Furthermore, it appears that published_version=>1
may only work
> when used by publish_another. Can anyone confirm if
that is the case?
> Our ideal situation is to grab the version that is
currently
> published, make the changes and republish; but if the
story is in a
> workflow and/or checked out we want to make the changes
to the
> prior published version, republish that version, and
also make
> changes to the version which is in a workflow without
publishing
> it. When pages are changed, we are able to send alerts
to the
> session user and whoever has checked out a document,
but so far we
> have not been able to pull a group of users based on
story id.
> Does anyone have suggestions about these two issues?
>
|