The following supporters have open issues assigned to them in this collector
(http://www.zope.org/Collectors/CMF).
Assigned and Open
efge
- "CMFSetup doesn't correctly detect DCWorkflow on export",
[Accepted] http://www.zope.org/Collectors/CMF/298
gregweb
- "CMFUid.UniqueId
David Pratt wrote:
Hi Raphael. Perhaps a workflow could be a solution.
[..]
Hope this helps.
Regards
David
Hi David,
that's indeed an interesting idea! Need to think about it more.
After some more meditation over the code I got most of
what I want now. Since it might be interesting fo
Hi Raphael!
Raphael Ritz wrote:
First, one needs to understand the processing chain:
[Zope]
1. FTP/DAV uploads call 'PUT' from 'webdav.NullResource'
[CMF]
2. This gets the 'PUT_factory' from the parent in spe
(the target) folder.
For CMF this is usually the one from 'PortalFolder'.
yuppie wrote:
[..]
7. ... it is placed in there.
(Why is this back-and-forth handling needed at all?)
CMF builds on top of Zope, so CMF's PortalFolder has to return a bare
and empty object as required by Zope's webdav machinery.
Hence the question is: Why does PortalFolder's PUT_factory
Hi Raphael
PS: Do people think it would be worthwhile documenting
this somehow? Or is this such a rare and special situation
that no-one would be interested in knowing?
Definately worthwhile! If it's documented, hopefully it will
become less rare and special.
--
Jean Jordaan
http://www.upfron
> PS: Do people think it would be worthwhile documenting
> this somehow? Or is this such a rare and special situation
> that no-one would be interested in knowing?
Documentation of stuff like this is always good. Even if it seems
like an edge case to you now - there may be many people who will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Raphael Ritz wrote:
> yuppie wrote:
> [..]
>
>>
>>> 7. ... it is placed in there.
>>>
>>> (Why is this back-and-forth handling needed at all?)
>>
>>
>>
>> CMF builds on top of Zope, so CMF's PortalFolder has to return a bare
>> and empty object as req
Is this actually a fix for http://www.zope.org/Collectors/CMF/333 as
opposed to 355?
On Wed, 2005-06-08 at 09:16 -0400, Tres Seaver wrote:
> Update of /cvs-repository/Products/CMFCore
> In directory cvs.zope.org:/tmp/cvs-serv12605/CMFCore
>
> Modified Files:
> Tag: CMF-1_4-branch
> FS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
> Is this actually a fix for http://www.zope.org/Collectors/CMF/333 as
> opposed to 355?
It addresses the FSImage part of 333, yes; the issues are basically
duplicates. I didn't check that FSFile had its own 'index_html', whi
