Etria Lists

 > Ah, yeah, the one-state workflow issue seems a bit of a pain.  I'm not
> sure what the right thing to do is here.  Perhaps worth asking on
> product-developers whether the lack of an 'effective' datetime is a bug
> in the workflow.  If the answer comes back "no", then I'm not sure what
> to do.  Any ideas?

It is not a one_state_workflow issue. I happened to find that out without 
asking. The same bug strikes whenever no state transition happens before a 
weblog entry reaches it's publication state. (This is naturally so for 
one_state_workflow.) You can verify this by changing the initial state of the 
Plone 3 default workflow from 'private' to 'published'. With Clouseau you 
also can easily check, that portal content of other types get their effective 
date  first set on workflow transition, not before. (In fact, the metadata 
tab suffices to see that). So the behavior of one_state_workflow is in 
perfect alignment with the other workflows. Btw., the effective date gets 
initialized in CMFPlone/skins/plone_form_scripts/content_status_modify.cpy, 
that is only through the web. WorkflowTool.doActionFor will not do so!

The issue lies with Quills excpecting effectiveDate to be initialized. The 
easiest way to fix this is to override WeblogEntry.getEffectiveDate so that 
it returns the creation date whenever effectiveDate is not set. Funny thing 
is (as I saw after I did this): 
Products.fatsyndication.feedentry.BaseFeedEntry.getEffectiveDate does exactly 
this. So this fix would not even break Quills semantics as they are 
inconsistent across subsystems already ;-)

I can prepare a patch for this. Though to be effective, it means dropping 
filtering blog entries by review_state=published. This is a fairly heavy 
change in behavior for a fix, though it makes the product behave more 
plonish.

> We already have this configurable-per-blog setup on QuillsEnabled.  See
> the getEntries method at
> <http://dev.plone.org/collective/browser/Products.QuillsEnabled/trunk/Produ
>cts/QuillsEnabled/adapters/folder.py>. The equivalent change should be made
> on Products.Quills (trunk), as well.  Can you do that?

I have not had a look at QuillsEnabled yet. Maybe if I find time after I 
migrated my site from COREBlog2 to Quills 1.6, I will try.

Jan Hackel

On Thursday 22 May 2008 23:05:40 you wrote:
> Jan Hackel wrote:
> > As bug report #126 (http://plone.org/products/quills/issues/126)
> > states, Quills 1.6 has problems with some workflows, for instance the
> > one state workflow. As I need to use different workflows than the
> > default ones I would like to so this fixed. However, I have some
> > difficulties seeing how this could be done, as it's mostly "by
> > design". Maybe someone one the list has some suggestions.
> >
> > Here is what's the problem:
> >
> > Quills makes some very specific assumptions about what "published" of
> > an entry means: 1) being in workflow state "published" and more
> > implicitly 2) having a slot "effective".
> >
> > The first problem is easy to be fixed, one must simply remove the
> > statement review_state = 'published' from the catalog query (e.g. in
> > Product.Quills.Weblog.getEntries). Quills should not make such
> > assumptions. In my opinion it is far better to leave visibility of
> > blog entries to Plone workflow and sharing. If reference to
> > "review_state" is needed, then the name of the actual published state
> >  should be configurable on per blog basis. However, I think this is
> > to much fuss. Is there anything speaking against the modification?
>
> We already have this configurable-per-blog setup on QuillsEnabled.  See
> the getEntries method at
> <http://dev.plone.org/collective/browser/Products.QuillsEnabled/trunk/Produ
>cts/QuillsEnabled/adapters/folder.py>. The equivalent change should be made
> on Products.Quills (trunk), as well.  Can you do that?
>
> As to th issue of whether we need to configure this at all, we had a
> short discussion about this on this list a few months ago.  Take a look
> in the archives for more details.
>
> > For the second problem, I am not quite sure if this is not a bug in
> > the one state workflow. Anyone knows more?
>
> Ah, yeah, the one-state workflow issue seems a bit of a pain.  I'm not
> sure what the right thing to do is here.  Perhaps worth asking on
> product-developers whether the lack of an 'effective' datetime is a bug
> in the workflow.  If the answer comes back "no", then I'm not sure what
> to do.  Any ideas?
>
>
> Tim