[Zope-CMF] trivial new portal folder type gives weird workflow/security behavior?

Florent Guillaume fg@nuxeo.com
29 Sep 2002 17:31:06 +0200


Well the standard content_status_modify doesn't take into account the
possibility of workflowed folders. It probably should, so yes please
fill a Collector issue to remind us.

There are two things to take into account: the redirect (don't append
/view for a folder) (the error you got in step 8), and the reindexing of
children to have their security correcly interpreted in the catalog
(call reindexObjectSecurity) (the visibility errors you had).

Florent

On Sun, 2002-09-29 at 17:11, chris wrote:
> doh! cheers florent, that totally solves my problem :-)
> 
> so, is the weirdness with publishing in step (9) one for the bug 
> collector - or should one basically 'know' not to workflow a Portal 
> Folder in that way (albeit accidentally in my case!)?
> 
> thanks again,
> regards,
> Chris.
> 
> >Go to portal_workflow and remove the (Default) workflow for your new
> >type.
> >
> >(/me is waiting for the "doh!" :-)
> >
> >Florent
> >
> >
> >chris  <chris@palefish.co.uk> wrote:
> >> Hullo all,
> >> 
> >> just for fun I wrote (yet another) ordered folder type (which you're all 
> >> very welcome to), in so doing I came across this strange and easily 
> >> reproducible behavior: a trivial new portal folder types magically seem 
> >> to become 'publishable', this subsequently seems to mess up the workflow 
> >> and security for its contained items. Is this a bug? Or, am I just 
> >> confused? (think I may know the answer to this last one already ;-)
> >> 
> >> The following creates a trivial new Portal Folder type and demonstrates 
> >> the proposed problem:
> >> 
> >> 1) create a new cmf-1.3 site: SERVER.COM / PORTAL
> >> 
> >> 2) in its portal_types, add a new factory-base-type-information with 
> >> id=FOO based on 'CMF:Core Portal Folder'
> >> 
> >> 3) create a new 'FOO' with id=BAR, i.e SERVER.COM / PORTAL / BAR
> >> 
> >> 4) goto the 'folder contents' of BAR, notice that it has a 'publish' 
> >> action - which wouldn't be there for a normal Portal Folder.
> >> 
> >> 5) create some documents X and Y inside BAR
> >> 
> >> 6) visit X and publish it.
> >> 
> >> 7) now check what's visible to the outside world; despite being 
> >> 'published', a request to SERVER.COM / PORTAL / BAR / X yields a 
> >> 'login_form'. Surely this isn't right?
> >> 
> >> ...but it gets worse...
> >> 
> >> 8) visit our folder-like object BAR and publish it (ignoring the error 
> >> that's produced)
> >> 
> >> 9) check again what the outside world can see; SERVER.COM / PORTAL / BAR 
> >> / X is now visible, which is good. But a request to the still 'private' 
> >> SERVER.COM / PORTAL / BAR / Y is also granted. Surely this isn't right 
> >> either?
> >> 
> >> Okay, demo over. So the question is: why don't trivial Portal Folder 
> >> derivatives behave nicely like real Portal Folders do? Is this a problem 
> >> with the FTI mechanism? Or have I _really_ misunderstood something? All 
> >> comments gratefully received!
> >> 
> >> Best regards,
> >> Chris.

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com