[Zope-CMF] Re: Bug when removing state in DCWorkflow
Tres Seaver wrote: [..] Objects which have a no-longer-sane review_state have *never* had reasonable behavior: the workflow engine *can't* compute what to do with them. They have no transitions (which is why the workflow actions are gone), and they can't be fixed by the Update Security button, because there *is no state* to whose permission map they can be conformed. With respect, this is a Doctor! Doctor! problem, to which the appropriate response is Take the spoon out of the glass before drinking (i.e., write the simple script which repairs the broken instances *before* deleting the state). Not really following the topic, so this might be too naive, sorry: Falling back to the workflow's initial state (like it's done on imports and when changing the workflow assigned to a type) in such cases wouldn't be an option? Raphael ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
this makes sense. i'm -1 on the final CMFonFive piece landing in CMF 1.6 itself, though. the original scope for CMF 1.6 was CMF 1.5 + GenericSetup, i don't see a compelling reason to complicate things by expanding that scope. if CMFonFive stays separate, then you can code it to support only Zope 2.9 without having to impose this same restriction on the CMF core. Well, it doesn't make sense, because it continues a complex versioning dance, and leaves many combinations unsupported, but if nobody else wants that fixed, then I won't fix it. :-) And it doesn't really complicate things by expanding any scope, it just moves a bit of code from on product to another. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 5 Jan 2006, at 09:40, Lennart Regebro wrote: this makes sense. i'm -1 on the final CMFonFive piece landing in CMF 1.6 itself, though. the original scope for CMF 1.6 was CMF 1.5 + GenericSetup, i don't see a compelling reason to complicate things by expanding that scope. if CMFonFive stays separate, then you can code it to support only Zope 2.9 without having to impose this same restriction on the CMF core. Well, it doesn't make sense, because it continues a complex versioning dance, and leaves many combinations unsupported, but if nobody else wants that fixed, then I won't fix it. :-) And it doesn't really complicate things by expanding any scope, it just moves a bit of code from on product to another. Sorry I didn't follow this discussion closely, so you want to merge the last remnants of CMFonFive into CMF 1.6 and 2.0, is that the suggestion? jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup: allowed_container_types
On 5 Jan 2006, at 12:05, yuppie wrote: I can't find any code for purge=False. This is only on the trunk. The _importNode methods of ActionCategoryNodeAdapter and ActionNodeAdapter look for an optional 'purge' attribute. Ah ok, I had looked at CMF 1.6 only. Workflow bindings don't need that attribute - they are always in update mode if self.environ.shouldPurge() is False. Maybe it would be better to make the shouldPurge setting the default for properties as well. And override it with purge=True if necessary. Don't know. On the other hand the object importer and the skins layer importer check insert-before and insert-after. I'll reuse that, even if in my use case the list order doesn't matter. On second thought it's a bit different, for skins and objects insert-before and insert-after are attributes of the (equivalent of the) element itself, not the property... So I'll put them on the elements, and make update the default if purge is true, and add an optional purge=True on the property if you really want to purge it in an extension profile. And on third thought you implemented remove=True. I'm not married to 'purge', but - we should be consistent for all kinds of sequences - remove doesn't feel right. If I see property name=lines2 remove=True I expect this property will be removed, not just cleared. - it actually overrides shouldPurge() I'm ok with 'purge' too. I named it 'remove' because of the existing uses of that keyword, and of not finding any use of purge. And if you see: property name=lines2 remove=True element value=Foo/ /property Then the behavior felt relatively natural: first remove, and then add what's here. But ok with purge. BTW: We should document these update directives somewhere. Originally all update directives were mentioned in CMFSetup/ PROFILES.txt. GenericSetup/PROFILES.txt no longer has a complete list because most update directives are CMF specific. I also agree, I need to point my developers to a doc somewhere with these special directives. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Jens Vagelpohl [EMAIL PROTECTED] wrote: Sorry I didn't follow this discussion closely, so you want to merge the last remnants of CMFonFive into CMF 1.6 and 2.0, is that the suggestion? It's already merged into CMF 2.0 (although it's not actuall *working* yet. ;) ) So it's only 1.6 that is the question yet. The result would be that CMF 1.6 would only support one major version of Zope, which I guess would be 2.9, which doesn't seem to sit well with the Plone community. Anyway, I'll release a CMFonFive 1.3 today, which will work with Zope 2.9, and CMF 1.5.5, and should work with CMF 1.6 (although I haven't tried it yet). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Bug when removing state in DCWorkflow
On Thu, 05 Jan 2006 13:07:07 +0100, Florent Guillaume [EMAIL PROTECTED] wrote: Tres Seaver wrote: Objects which have a no-longer-sane review_state have *never* had reasonable behavior: the workflow engine *can't* compute what to do with them. They have no transitions (which is why the workflow actions are gone), and they can't be fixed by the Update Security button, because there *is no state* to whose permission map they can be conformed. This always worked in earlier versions, and has always been the way to get people who don't know how to script CMF to modify workflows. The rule was simple: If you remove a state and click the Update Security button, the objects that are in the state that no longer exists will fall back to the initial state. This has stopped working. Whether it was intentional or not, this behaviour was useful, consistent, and exists in a lot of documentation out there, even a few of the Plone books, IIRC. Raphael Ritz wrote: Not really following the topic, so this might be too naive, sorry: Falling back to the workflow's initial state (like it's done on imports and when changing the workflow assigned to a type) in such cases wouldn't be an option? That's what it used to do. It no longer does. Florent Guillaume: That's been the intent of the code all along: when you query the workflow tool and ask it for the state of an object, this is passed along to DCWorkflow, and if the object doesn't have a state anymore the initial state is returned. However if you remove a valid state, nothing queries and recatalogs all the objects, so they still have an old review_state in the catalog. Update security settings is for a different use case, I'm not sure it should be retrofitted into doing this. So why did it work in earlier CMF versions? I'm curious. :) The reason why this is so important to me is that it removes the ability for non-developers to do any sort of meaningful change to the workflow. Removing a state and having the objects in that state fall back to the initial state is extremely useful - whether it was intentional or not. -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMFPhoto + Album broken in 2.1.1
Is there a fix for: When installing CMFPhoto and Album from Add/Remove Products, it says the product is broken with the following Install log transcript: 2006-01-05 09:23:33 failed: Traceback (most recent call last): File /opt/zope/2.8.4/Products/CMFQuickInstallerTool/QuickInstallerTool.py, line 311, in installProduct res=install(portal) File /usr/local/zope/2.8.4/lib/python/Products/ExternalMethod/ExternalMethod.py, line 225, in __call__ try: return f(*args, **kw) File /opt/zope/2.8.4/Products/CMFPhoto/Extensions/Install.py, line 43, in install nav=portal_prop.navigation_properties AttributeError: navigation_properties ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMFPhoto + Album broken in 2.1.1
Ignacio Valdes wrote: Is there a fix for: When installing CMFPhoto and Album from Add/Remove Products, it says the product is broken with the following Install log transcript: Your Plone is too new ;-) Plone doesn't have nor use the navigation_properties since 2.0 (about two years ago) Raphael 2006-01-05 09:23:33 failed: Traceback (most recent call last): File /opt/zope/2.8.4/Products/CMFQuickInstallerTool/QuickInstallerTool.py, line 311, in installProduct res=install(portal) File /usr/local/zope/2.8.4/lib/python/Products/ExternalMethod/ExternalMethod.py, line 225, in __call__ try: return f(*args, **kw) File /opt/zope/2.8.4/Products/CMFPhoto/Extensions/Install.py, line 43, in install nav=portal_prop.navigation_properties AttributeError: navigation_properties ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Plone add item restriction based on context/group/role?
Hello all, I would like to restrict what a Plone user can add based on the folder they are currently navigating in. For instance, I have a folder named My Protocols. I only want a user that is a member of the group 'Staff' to be able to add 1) folders. 2) CMFQuestion questionnaires and 3) a custom Archtype 'protocol' item to My Protocols and its sub-folders. No other items should be addable in that folder. Similarly, I want to restrict the ability to add 'protocol' archtype to any other folder except My Protocols or its sub-folders. In short, the ability of any user that is a member of group 'staff' to create a protocol should only be able to happen in folder 'My Protocols'. How does one do this in Plone? Thanks! -- IV ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMFPhoto + Album broken in 2.1.1
Ut-oh. The Add/Remove Products tells me ' This product has been upgraded, click here to reinstall. Filesystem version is' but when I click it gives: Site error This site encountered an error trying to fulfill your request. The errors were: Error Type AttributeError Error Value navigation_properties Request made at 2006/01/05 10:43:29.913 US/Central -- IV On Thu, 05 Jan 2006 16:44:24 +0100 Raphael Ritz [EMAIL PROTECTED] wrote: Ignacio Valdes wrote: Is there a fix for: When installing CMFPhoto and Album from Add/Remove Products, it says the product is broken with the following Install log transcript: Your Plone is too new ;-) Plone doesn't have nor use the navigation_properties since 2.0 (about two years ago) Raphael 2006-01-05 09:23:33 failed: Traceback (most recent call last): File /opt/zope/2.8.4/Products/CMFQuickInstallerTool/QuickInstallerTool.py, line 311, in installProduct res=install(portal) File /usr/local/zope/2.8.4/lib/python/Products/ExternalMethod/ExternalMethod.py, line 225, in __call__ try: return f(*args, **kw) File /opt/zope/2.8.4/Products/CMFPhoto/Extensions/Install.py, line 43, in install nav=portal_prop.navigation_properties AttributeError: navigation_properties ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Simple way of CMFQuestion questionnaire as a Add item?
Hello again all, I have created a nice CMFQuestion questionnaire that I would like to be available on the Add item dropdown. So instead of adding a generic questionnaire from Add item, you would be able to add an already populated questionnaire. Is there a simple way of doing this? Can you tell I have a demo January 10th? -- IV ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Bug when removing state in DCWorkflow
Alexander Limi wrote: Florent Guillaume: That's been the intent of the code all along: when you query the workflow tool and ask it for the state of an object, this is passed along to DCWorkflow, and if the object doesn't have a state anymore the initial state is returned. However if you remove a valid state, nothing queries and recatalogs all the objects, so they still have an old review_state in the catalog. Update security settings is for a different use case, I'm not sure it should be retrofitted into doing this. So why did it work in earlier CMF versions? I'm curious. :) How early? The current code calls: ob.reindexObject(idxs=['allowedRolesAndUsers']) for updated objects, and it's been that since July 2002. The review state is *not* reindexed. Which is only normal for a method called updateRoleMappings. The reason why this is so important to me is that it removes the ability for non-developers to do any sort of meaningful change to the workflow. Removing a state and having the objects in that state fall back to the initial state is extremely useful - whether it was intentional or not. I understand the use case. It's just that it's not something the code was ever supposed to do. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Plone add item restriction based on context/group/role?
I've found the partial answer through the 'Settings...' on the drop down only it doesn't seem to want to save my restrictions. -- IV On Thu, 05 Jan 2006 09:46:28 -0600 Ignacio Valdes [EMAIL PROTECTED] wrote: Hello all, I would like to restrict what a Plone user can add based on the folder they are currently navigating in. For instance, I have a folder named My Protocols. I only want a user that is a member of the group 'Staff' to be able to add 1) folders. 2) CMFQuestion questionnaires and 3) a custom Archtype 'protocol' item to My Protocols and its sub-folders. No other items should be addable in that folder. Similarly, I want to restrict the ability to add 'protocol' archtype to any other folder except My Protocols or its sub-folders. In short, the ability of any user that is a member of group 'staff' to create a protocol should only be able to happen in folder 'My Protocols'. How does one do this in Plone? Thanks! -- IV ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Plone add item restriction based on context/group/role?
Ignacio Valdes wrote: I've found the partial answer through the 'Settings...' on the drop down only it doesn't seem to want to save my restrictions. This 'Settings ...' option is actually purely Plone/ATCT specific. You might have better chances to get an answer to your question on the plone-users list. Raphael PS: Look for the 'ContrainTypesMixin' class to see how this feature works. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Plone add item restriction based on context/group/role?
Ah-hah! I was wondering if such lists existed: http://plone.org/contact/index_html/?searchterm=plone-users%20list Wish there was a tab for this on plone.org -- IV On Thu, 05 Jan 2006 18:12:19 +0100 Raphael Ritz [EMAIL PROTECTED] wrote: Ignacio Valdes wrote: I've found the partial answer through the 'Settings...' on the drop down only it doesn't seem to want to save my restrictions. This 'Settings ...' option is actually purely Plone/ATCT specific. You might have better chances to get an answer to your question on the plone-users list. Raphael PS: Look for the 'ContrainTypesMixin' class to see how this feature works. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Plone add item restriction based on context/group/role?
Ignacio Valdes wrote: Ah-hah! I was wondering if such lists existed: http://plone.org/contact/index_html/?searchterm=plone-users%20list Wish there was a tab for this on plone.org Your wish is granted. It's the contact tab, though that doesn't seem like the best name. --jcc -- Building Websites with Plone http://plonebook.packtpub.com/ Enfold Systems, LLC http://www.enfoldsystems.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
Lennart Regebro wrote: this makes sense. i'm -1 on the final CMFonFive piece landing in CMF 1.6 itself, though. the original scope for CMF 1.6 was CMF 1.5 + GenericSetup, i don't see a compelling reason to complicate things by expanding that scope. if CMFonFive stays separate, then you can code it to support only Zope 2.9 without having to impose this same restriction on the CMF core. Well, it doesn't make sense, because it continues a complex versioning dance, and leaves many combinations unsupported, but if nobody else wants that fixed, then I won't fix it. :-) maybe i'm being dense, but i don't see how merging the code into the CMF core improves this. if i'm understanding this correctly, you wouldn't be increasing the number of supported combinations at all; you'd just have expanded one of the Z2.8 unsupported pieces from a single feature (menu - action bridging) to the entirety of CMF 1.6. anyway, it's moot, since you've agreed to keep it a separate product for now. thank you. CMF 2.0 will see all of this converge. -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Rob Miller [EMAIL PROTECTED] wrote: maybe i'm being dense, but i don't see how merging the code into the CMF core improves this. if i'm understanding this correctly, you wouldn't be increasing the number of supported combinations at all; No, I'd just get rid of a whole lot of potential version combinations, thereby lessening the support headache that this already is. Although I admittedly can handle that problem by completely ignoring it, which seems to be the preferred option here. And I just realized that Five 1.3 and Five in 1.2 differs much more than I thought too. Glaaah. :-P And CMF 1.6 already has more changes that just GenericSetup, some of which are already causing me other headaches. I guess my main problem is that everything else is currently changing so fast that I don't have time to keep up with the changes, and the more stuff I fix, the more stuff seems to remain to be fixed. CalZope 2.0 (which is needed for the CalPlone implementation) just looks further and further away. :-/ anyway, it's moot, since you've agreed to keep it a separate product for now. thank you. Yeah, but that doesn't mean I like it. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
Lennart Regebro wrote: And CMF 1.6 already has more changes that just GenericSetup, some of which are already causing me other headaches. which are these? the most significant changes are in the TypesTool, and this was done in order to achieve more parity btn the 1.6 and 2.0 site creation code... there's nothing that i know of that's not directly related to the GenericSetup stuff. I guess my main problem is that everything else is currently changing so fast that I don't have time to keep up with the changes, and the more stuff I fix, the more stuff seems to remain to be fixed. CalZope 2.0 (which is needed for the CalPlone implementation) just looks further and further away. :-/ i don't foresee any further changes w/ CMF 1.6, unless there are further changes in GenericSetup that force the issue. hopefully GS is stabilizing a bit. anyway, it's moot, since you've agreed to keep it a separate product for now. thank you. Yeah, but that doesn't mean I like it. :-) i'm not too happy about it myself, truth be told, but i don't see another option just yet. -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Rob Miller [EMAIL PROTECTED] wrote: Lennart Regebro wrote: And CMF 1.6 already has more changes that just GenericSetup, some of which are already causing me other headaches. which are these? the most significant changes are in the TypesTool, and this was done in order to achieve more parity btn the 1.6 and 2.0 site creation code... there's nothing that i know of that's not directly related to the GenericSetup stuff. Yeah, well that's it. And here I am trying to achieve more parity between 1.6 and 2.0. [ Well, now I'm only teasing you on accord of the wobbly argumentation. ;-) ] -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
