Optional Cover Date?

Hi All,

I just noticed that I was able to set the cover date in a
non-fixed  
story to be empty. So then my non-fixed story ended up with
a URI with  
no date. This just seems wrong to me.

Can anyone think of a reason not to require a cover date for
all  
stories? Can you all run this query and let me know if you
have any  
valid stories (or media) without cover dates?

select count(story__id) from story_instance where cover_date
is null
union
select count(media__id) from media_instance where cover_date
is null;

You should get:

  count
-------
      0
      0
(2 rows)

Thanks,

David

On Wed, 16 Apr 2008, David E. Wheeler wrote:
> I just noticed that I was able to set the cover date in
a non-fixed story to
> be empty. So then my non-fixed story ended up with a
URI with no date. This
> just seems wrong to me.
>
> Can anyone think of a reason not to require a cover
date for all stories? Can
> you all run this query and let me know if you have any
valid stories (or
> media) without cover dates?
>
> select count(story__id) from story_instance where
cover_date is null
> union
> select count(media__id) from media_instance where
cover_date is null;
>
> You should get:
>
> count
> -------
>    0
>    0
> (2 rows)

Corresponding 1.8 queries from our system:

bricolage=> select count(id) from story where cover_date
is null and active=1;
  count
-------
     24
(1 row)

bricolage=> select count(id) from media where cover_date
is null and active=1;
  count
-------
      1
(1 row)

I'm not sure how we're defining "valid story" or
"valid media", however.
Everyone one of our assets is of course precious and of
vital importance.
To someone.

David E. Wheeler wrote:
> 
> select count(story__id) from story_instance where
cover_date is null
> union
> select count(media__id) from media_instance where
cover_date is null;
> 

I get 0,0 on our main CMS and 21 stories and 1 media on our
multi site 
CMS. Looking further the stories in the multi site one were
all inserted 
via SOAP so I assume for some reason the cover date wasn't
passed in 
with the story at insertion point.

An easy fix would be to make sure that the $asset->save
call sets the 
coverdate to be now() if it's blank. That way it can't ever
be set to 
blank.

regards,

Paul.

On Apr 17, 2008, at 01:46, Paul Orrock wrote:

> I get 0,0 on our main CMS and 21 stories and 1 media on
our multi  
> site CMS. Looking further the stories in the multi site
one were all  
> inserted via SOAP so I assume for some reason the cover
date wasn't  
> passed in with the story at insertion point.
>
> An easy fix would be to make sure that the
$asset->save call sets  
> the coverdate to be now() if it's blank. That way it
can't ever be  
> set to blank.

Yes, and I'd add a NOT NULL constraint on the database, too.
But to do  
so, I'd have to write an upgrade script to set the cover
date for  
those that are missing it, probably from first_publish_date.
Any  
objections? Scott, can you look at those 24 stories and 1
media do see  
what the deal is with them, or at least to get an idea?

Thanks,

David

On Thu, 17 Apr 2008, David E. Wheeler wrote:
> On Apr 17, 2008, at 01:46, Paul Orrock wrote:
>> I get 0,0 on our main CMS and 21 stories and 1
media on our multi site CMS. 
>> Looking further the stories in the multi site one
were all inserted via 
>> SOAP so I assume for some reason the cover date
wasn't passed in with the 
>> story at insertion point.
>> 
>> An easy fix would be to make sure that the
$asset->save call sets the 
>> coverdate to be now() if it's blank. That way it
can't ever be set to 
>> blank.
>
> Yes, and I'd add a NOT NULL constraint on the database,
too. But to do so, 
> I'd have to write an upgrade script to set the cover
date for those that are 
> missing it, probably from first_publish_date. Any
objections? Scott, can you 
> look at those 24 stories and 1 media do see what the
deal is with them, or at 
> least to get an idea?

I don't see any obvious pattern to them,
arbitrary categories and publish_dates... no idea.
Probably bric_soap-related as for Paul.
They do have first_publish_date and publish_date non-NULL.

On Thu, Apr 17, 2008 at 09:46:48AM +0100, Paul Orrock
wrote:
> David E. Wheeler wrote:
> >
> >select count(story__id) from story_instance where
cover_date is null
> >union
> >select count(media__id) from media_instance where
cover_date is null;
> >
> 
> I get 0,0 on our main CMS and 21 stories and 1 media on
our multi site 
> CMS. Looking further the stories in the multi site one
were all inserted 
> via SOAP so I assume for some reason the cover date
wasn't passed in 
> with the story at insertion point.
> 
> An easy fix would be to make sure that the
$asset->save call sets the 
> coverdate to be now() if it's blank. That way it can't
ever be set to 
> blank.

I'm not still not sure if it'd be usefull to have an undated
article, but if the policy _is_ to require it, I don't think
I like the automagic installation of dates... I'd rather it
throw and error and say "Finish your job, person
creating this story".

> regards,
> 
> Paul.

-- 

Brad Harder,
Method Digital Logic
http://www.methodlogic.net

I'm coming late to this, but I've run into precisely this
issue with the
Observer site.

uco=> select count(story__id) from story_instance where
cover_date is
null union select count(media__id) from media_instance where
cover_date
is null;
 count 
-------
     0
   129
(2 rows)


All these cover-date-less story instances are author bios,
which are
created by a utility template when a story is published and
one of its
contributors does not already have a bio story.

The template doing the creating does not pass a cover date
in to
$story->new. At first, I thought this was OK, because the
bio stories
looked fine and published fine, and had static URIs.

But. The bio stories themselves use
image_resize_and_relate.mc to make
small standard size versions of author mugshots, and those
mugshots need
cover dates for their own URIs, and
image_resize_and_relate.mc uses the
cover date of the parent story to set the cover date of new
media it
creates.

So I've been manually adding cover dates to bio stories.

One more bit of weirdness: I tried to have
publish_author_story.mc take
the cover date from the originating story, but that resulted
in an
error. Each time I tried to publish a story with a new
contributor, an
error would tell me that the story with (UUID) was not
associated with
any categories. I imagine the story it meant was the new
bio, becuase it
showed a new UUID in the error every time I tried the
publish.

So a limited set of initial parameters for $story->new
allowed was OK,
sort of, as long as the cover date was missing. But once
cover date was
in the mix, Bricolage wanted a category as well.

Here's publish_author_story.mc. You can see the commented
out
date-setter.

Just for reference, does anyody know the minimum set of
initial
parameters that $story->new wants? Maybe it would be good
to auto-set
(or insist on ) those. Heck, maybe even I could do that
patch.  I'll
try, anyhow.


Cheers,

Bret




<%doc>

=head1 NAME
	
publish_author_story.mc

=head1 SYNOPSIS

# create author story(s) for the contributors associated
with this feature, if they don't already exist
    foreach my $contributor ($story->get_contributors) {
       $m->comp('/util/publish_author_story.mc',
contributor => $contributor);
      }


=head1 DESCRIPTION 

Looks for an existing author story for this contributor
object
If an author story doesn't exist for this contributor (and
there isn't a same URI for an different contributor) create
it and publish it

</%doc>

<%args>
$contributor =>  undef #this value should be sent via the
story template that calls this template
$contrib_id => undef
$story_slug => undef
$author_story_element =>
Bric::Biz::ElementType->lookup({key_name =>
'author'})
</%args>

<%init>
# We need a contributor object to get the ball rolling.
$burner->throw_error("There is no contributor, you
need to add one.")
	       unless $contributor;   

$contrib_id = $contributor->get_id;

my ($author_category) = Bric::Biz::Category->list({
         uri => '/author/',
   });
   

$burner->throw_error("There is no /author/ category,
you need to create one.")
	       unless $author_category;  
	       
	       
#format the slug using the contributor name
$story_slug =
$m->comp("/util/authorname_to_slug.mc",
contrib=> $contributor);
my $author_category_uri = $author_category->get_uri;  
my $story_uri = lc($author_category_uri.$story_slug).'/';



</%init>

<%perl>
# Looks for an existing author.mc story with this same
contributor associated
my ($author_story) = $story->list({
     contrib_id => $contrib_id,
     element_key_name => 'author',
	 Limit            => 1,
     unexpired         => 1, # No expired stories!
     #published_version => 1, # should this be looking
for unpublished as well?
   
});


# Now look for an existing author.mc story with another
contributor but the same URI (these things can happen!)
my ($author_story_sameuri) = $story->list({
     #contrib_id => $contrib_id,
     element_key_name => 'author',
     uri => $story_uri,
	 Limit            => 1,
     unexpired         => 1, # No expired stories!
     published_version => 1, # should this be looking for
unpublished as well?
   
});

# this makes me wonder if names should have numbers in the
URI corresponding to contributor ID? Or a date corrosponding
to when they were added?
#$burner->throw_error("An author story with the URI
".$story_uri. " already exists. You need to
differentiate these contributor names to make the slugs
different.")
#	       if $author_story_sameuri; 


unless ($author_story){
   # We need to create a new author story for this
contributor.
   $author_story =
Bric::Biz::Asset::Business::Story->new({
         element_type => $author_story_element,
         source__id  => $story->get_source__id,
         site_id     => $story->get_site_id,
         user__id    =>
Bric::App::Session::get_user_id(),
         title       =>
$contributor->get_name("Author :: %f% m% l"),
         #cover_date  => $story->get_cover_date, # you
can change this 
         slug        => $story_slug,
         
     });
 
   # Set it up and check it in.
     $author_story->add_categories( [
$author_category->get_id ] );
     $author_story->set_primary_category(
$author_category->get_id );  
     $author_story->add_contributor($contrib_id);
     Bric::App::Util::add_msg( 'New Author story created for
author '.$contributor->get_name('%f% m% l'));
     $author_story->checkin;
     $author_story->save;
      
   # Publish
     $burner->publish_another($author_story);    
}

</%perl>





On Wed, 2008-04-16 at 15:16 -0700, David E.Wheeler wrote:
> Hi All,
> 
> I just noticed that I was able to set the cover date in
a non-fixed  
> story to be empty. So then my non-fixed story ended up
with a URI with  
> no date. This just seems wrong to me.
> 
> Can anyone think of a reason not to require a cover
date for all  
> stories? Can you all run this query and let me know if
you have any  
> valid stories (or media) without cover dates?
> 
> select count(story__id) from story_instance where
cover_date is null
> union
> select count(media__id) from media_instance where
cover_date is null;
> 
> You should get:
> 
>   count
> -------
>       0
>       0
> (2 rows)
> 
> Thanks,
> 
> David
> 
-- 
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com

On Apr 18, 2008, at 06:57, Scott Lanning wrote:

> I don't see any obvious pattern to them,
> arbitrary categories and publish_dates... no idea.
> Probably bric_soap-related as for Paul.
> They do have first_publish_date and publish_date
non-NULL.

Did you look at them on the site, maybe to see if a dateline
is  
screwed up in the output?

Best,

David

On Apr 18, 2008, at 08:08, bharder wrote:

> I'm not still not sure if it'd be usefull to have an
undated  
> article, but if the policy _is_ to require it, I don't
think I like  
> the automagic installation of dates... I'd rather it
throw and error  
> and say "Finish your job, person creating this
story".

Well, they default to "now", but we would of
course throw an error if  
someone removed a cover date.

Best,

David

On Apr 18, 2008, at 08:32, Bret Dawson wrote:

> But. The bio stories themselves use
image_resize_and_relate.mc to make
> small standard size versions of author mugshots, and
those mugshots  
> need
> cover dates for their own URIs, and
image_resize_and_relate.mc uses  
> the
> cover date of the parent story to set the cover date of
new media it
> creates.
>
> So I've been manually adding cover dates to bio
stories.

Bleh. That doesn't sound fun.

> One more bit of weirdness: I tried to have
publish_author_story.mc  
> take
> the cover date from the originating story, but that
resulted in an
> error. Each time I tried to publish a story with a new
contributor, an
> error would tell me that the story with (UUID) was not
associated with
> any categories. I imagine the story it meant was the
new bio,  
> becuase it
> showed a new UUID in the error every time I tried the
publish.

Odd.

> So a limited set of initial parameters for
$story->new allowed was OK,
> sort of, as long as the cover date was missing. But
once cover date  
> was
> in the mix, Bricolage wanted a category as well.

That's probably because it was properly checking the URI. So
set the  
cover date separately, after you set the category. So,
pseudo-code:

   my $s = Story->new(...);
   $s->add_category($cat);
   $s->set_primary_category($cat);
   $s->set_cover_date( $date );

> Here's publish_author_story.mc. You can see the
commented out
> date-setter.
>
> Just for reference, does anyody know the minimum set of
initial
> parameters that $story->new wants? Maybe it would be
good to auto-set
> (or insist on ) those. Heck, maybe even I could do that
patch.  I'll
> try, anyhow.

That would be nice. I don't know the minimum, but you can
look at the  
source for new() and at Bric::App::Callback::Profile::Story
for  
examples.

Best,

David