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

[chris]

just for the record:
http://collector.zope.org/CMF/62

>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
>
>
>_______________________________________________
>Zope-CMF maillist  -  Zope-CMF@zope.org
>http://lists.zope.org/mailman/listinfo/zope-cmf
>
>See http://collector.zope.org/CMF for bug reports and feature requests
>  
>