[Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Hi! Moving the notifyWorkflowCreated call from _finishConstruction to the IObjectAddedEvent subscriber changed the behavior of .zexp imports: The workflow state is now always reset to the initial state. AFAICT that's no useful behavior for imports. This is caused by the fact that the notifyCreated method of WorkflowTool always resets the workflow states. Is that a feature or a bug of notifyCreated? Is anybody using notifyCreated for resetting workflow states? Where is the best place to fix this? Should IObjectAddedEvent be triggered on imports? Should the subscriber call notifyWorkflowCreated if the object already has a workflow history? Should notifyWorkflowCreated call WorkflowTool.notifyCreated if the object already has a workflow history? Should WorkflowTool.notifyCreated call notifyCreated of workflows that already have a state? Should notifyCreated of workflows keep existing states untouched? AFAICS the easiest way to fix this is changing WorkflowTool.notifyCreated, making sure it only calls notifyCreated for workflows without a state in the workflow history. Any objections or better ideas? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Moving the notifyWorkflowCreated call from _finishConstruction to the > IObjectAddedEvent subscriber changed the behavior of .zexp imports: The > workflow state is now always reset to the initial state. AFAICT that's > no useful behavior for imports. > > This is caused by the fact that the notifyCreated method of WorkflowTool > always resets the workflow states. > > Is that a feature or a bug of notifyCreated? Is anybody using > notifyCreated for resetting workflow states? > > Where is the best place to fix this? Should IObjectAddedEvent be > triggered on imports? Should the subscriber call notifyWorkflowCreated > if the object already has a workflow history? Should > notifyWorkflowCreated call WorkflowTool.notifyCreated if the object > already has a workflow history? Should WorkflowTool.notifyCreated call > notifyCreated of workflows that already have a state? Should > notifyCreated of workflows keep existing states untouched? > > > AFAICS the easiest way to fix this is changing > WorkflowTool.notifyCreated, making sure it only calls notifyCreated for > workflows without a state in the workflow history. +1. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnEdu+gerLs4ltQ4RAoMSAKCEyP2CN5EfonXqkZSIGjLfHLqM+wCfYtEC /pYBguVEQhbri7sVoAtbJsM= =AwXA -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Hi! Tres Seaver wrote: > yuppie wrote: >> Moving the notifyWorkflowCreated call from _finishConstruction to the >> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The >> workflow state is now always reset to the initial state. AFAICT that's >> no useful behavior for imports. >> >> This is caused by the fact that the notifyCreated method of WorkflowTool >> always resets the workflow states. >> >> Is that a feature or a bug of notifyCreated? Is anybody using >> notifyCreated for resetting workflow states? It turned out that CMF itself uses notifyCreated for resetting workflow states :( That's how copy and paste resets the workflow state. >> Where is the best place to fix this? Should IObjectAddedEvent be >> triggered on imports? Should the subscriber call notifyWorkflowCreated >> if the object already has a workflow history? Should >> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object >> already has a workflow history? Should WorkflowTool.notifyCreated call >> notifyCreated of workflows that already have a state? Should >> notifyCreated of workflows keep existing states untouched? >> >> >> AFAICS the easiest way to fix this is changing >> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for >> workflows without a state in the workflow history. > > +1. This alone will not work. Does it make sense to keep old workflow history records after copy and paste? Or can we just remove the complete workflow_history attribute before notifyCreated is called? If the subscriber for IObjectCopiedEvent removes the workflow_history everything seems to work fine. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Previously yuppie wrote: > Tres Seaver wrote: > > yuppie wrote: > >> Moving the notifyWorkflowCreated call from _finishConstruction to the > >> IObjectAddedEvent subscriber changed the behavior of .zexp imports: The > >> workflow state is now always reset to the initial state. AFAICT that's > >> no useful behavior for imports. > >> > >> This is caused by the fact that the notifyCreated method of WorkflowTool > >> always resets the workflow states. > >> > >> Is that a feature or a bug of notifyCreated? Is anybody using > >> notifyCreated for resetting workflow states? > > It turned out that CMF itself uses notifyCreated for resetting workflow > states :( > > That's how copy and paste resets the workflow state. Which is argueably a mis-feature: it means you are not just doing a copy and paste, but a copy, paste and modify. > >> Where is the best place to fix this? Should IObjectAddedEvent be > >> triggered on imports? Should the subscriber call notifyWorkflowCreated > >> if the object already has a workflow history? Should > >> notifyWorkflowCreated call WorkflowTool.notifyCreated if the object > >> already has a workflow history? Should WorkflowTool.notifyCreated call > >> notifyCreated of workflows that already have a state? Should > >> notifyCreated of workflows keep existing states untouched? > >> > >> > >> AFAICS the easiest way to fix this is changing > >> WorkflowTool.notifyCreated, making sure it only calls notifyCreated for > >> workflows without a state in the workflow history. > > > > +1. > > This alone will not work. > > Does it make sense to keep old workflow history records after copy and > paste? Or can we just remove the complete workflow_history attribute > before notifyCreated is called? In my opinion a copy should produce a full copy, including all state and history. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
On 2/18/09 12:35 PM, "yuppie" wrote: > Does it make sense to keep old workflow history records after copy and > paste? Or can we just remove the complete workflow_history attribute > before notifyCreated is called? I think it shouldn't be kept...and over time this history tends to get quite large. On my last 2 projects, we have had to address this by changing the default implementation. > > If the subscriber for IObjectCopiedEvent removes the workflow_history > everything seems to work fine. > +1 > > Cheers, > > Yuppie > > ___ > Zope-CMF maillist - Zope-CMF@lists.zope.org > http://mail.zope.org/mailman/listinfo/zope-cmf > > See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Hi! Wichert Akkerman wrote: > Previously yuppie wrote: >> Does it make sense to keep old workflow history records after copy and >> paste? Or can we just remove the complete workflow_history attribute >> before notifyCreated is called? > > In my opinion a copy should produce a full copy, including all state and > history. There are several tests for the current behavior in test_Image, so it is intended behavior. Do you propose to change the current policy? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Wichert Akkerman wrote at 2009-2-18 21:51 +0100: > ... >> That's how copy and paste resets the workflow state. > >Which is argueably a mis-feature: it means you are not just doing a copy >and paste, but a copy, paste and modify. > ... >In my opinion a copy should produce a full copy, including all state and >history. For some workflows, it may not be adequate to retain the state after a copy. Consider a publication workflow with a site organized along subjects with different subject reviewers. Object "o" is released in subject "s1". Now it is copied to subject "s2". I think it is obvious that "o" needs a review at its new place. In addition: I is highly doubtfull that the "creation_date" of the copy should be the same as the creation date of the original. At least in our contexts, copies are usually made to be modified later (slightly). For this use case, the "creation_date" should be set to the time the copy was created *and* the copy should start in the initial state. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Am 18.02.2009 um 21:51 schrieb Wichert Akkerman: > In my opinion a copy should produce a full copy, including all state > and > history. Yes, in the technical sense of .copy() but I'm not sure if that is what I as a user expect in a CMS. Do I really want an exact duplicate of everything or perhaps a new object with the content of the old? If the original object has already been published should my new object also be published? If so surely I'm breaking with the workflow principle. In my experience (and I'm not just talking about how I do things) copies are usually made with the original object being archived as a sort of security blanket in case something goes wrong. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Charlie Clark wrote: > Am 18.02.2009 um 21:51 schrieb Wichert Akkerman: > >> In my opinion a copy should produce a full copy, including all state >> and >> history. Not sure I would agree here. For a move (cut&paste) yes but for a copy I think there are too many different use cases to justify your claim above. > > > Yes, in the technical sense of .copy() but I'm not sure if that is > what I as a user expect in a CMS. Do I really want an exact duplicate > of everything or perhaps a new object with the content of the old? If > the original object has already been published should my new object > also be published? If so surely I'm breaking with the workflow > principle. > > In my experience (and I'm not just talking about how I do things) > copies are usually made with the original object being archived as a > sort of security blanket in case something goes wrong. ... and not to forget the common copy/paste/modify pattern to create new content. Here as well I'd say starting out with the initial workflow state (and new creation date/creator settings) is the right thing to do. Just my 2 cents, Raphael > > Charlie > -- > Charlie Clark > Helmholtzstr. 20 > Düsseldorf > D- 40215 > Tel: +49-211-938-5360 > GSM: +49-178-782-6226 > > > > ___ > Zope-CMF maillist - Zope-CMF@lists.zope.org > http://mail.zope.org/mailman/listinfo/zope-cmf > > See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests > ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Previously Raphael Ritz wrote: > Charlie Clark wrote: > > Am 18.02.2009 um 21:51 schrieb Wichert Akkerman: > > > >> In my opinion a copy should produce a full copy, including all state > >> and > >> history. > > Not sure I would agree here. > For a move (cut&paste) yes but for a copy I think > there are too many different use cases to justify > your claim above. There are many use cases for both options. One aspect is that it is extremely hard to not get the current behaviour. We had to hire Philipp to write z3c.unconfigure for us just to be able to create a system to prevent CMF from making changes on copies. Wichert -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Am 25.02.2009 um 14:18 schrieb Wichert Akkerman: > There are many use cases for both options. One aspect is that it is > extremely hard to not get the current behaviour. We had to hire > Philipp > to write z3c.unconfigure for us just to be able to create a system > to prevent CMF from making changes on copies. First of all I'm not sure if that's such a bad thing! ;-) But the solution would probably be making this behaviour configurable somewhere in the workflow tool. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Wichert Akkerman wrote: > Previously Raphael Ritz wrote: >> Charlie Clark wrote: >>> Am 18.02.2009 um 21:51 schrieb Wichert Akkerman: >>> In my opinion a copy should produce a full copy, including all state and history. >> Not sure I would agree here. >> For a move (cut&paste) yes but for a copy I think >> there are too many different use cases to justify >> your claim above. > > There are many use cases for both options. One aspect is that it is > extremely hard to not get the current behaviour. There I do agree and I also more than once had the wish for more flexibility/configurability. > We had to hire Philipp > to write z3c.unconfigure for us just to be able to create a system > to prevent CMF from making changes on copies. > :-( Raphael > Wichert > ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Previously Charlie Clark wrote: > > Am 25.02.2009 um 14:18 schrieb Wichert Akkerman: > > > There are many use cases for both options. One aspect is that it is > > extremely hard to not get the current behaviour. We had to hire > > Philipp > > to write z3c.unconfigure for us just to be able to create a system > > to prevent CMF from making changes on copies. > > > First of all I'm not sure if that's such a bad thing! ;-) > > But the solution would probably be making this behaviour configurable > somewhere in the workflow tool. The workflow tool is not a factor at all here. The problem is that CMF registers some event handlers that do things like clear workflow status and local roles when you create a copy. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: > The workflow tool is not a factor at all here. The problem is that CMF > registers some event handlers that do things like clear workflow > status > and local roles when you create a copy. I realise that but surely the handlers can have a default behaviour that can be changed depending on the configuration? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Previously Charlie Clark wrote: > Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: > > The workflow tool is not a factor at all here. The problem is that CMF > > registers some event handlers that do things like clear workflow > > status > > and local roles when you create a copy. > > I realise that but surely the handlers can have a default behaviour > that can be changed depending on the configuration? In my opinion they should not be globally registered at all, but available for registration in a local site manager. CMFDefault could then do that registration for its needs. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Charlie Clark wrote: >> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: >>> The workflow tool is not a factor at all here. The problem is that CMF >>> registers some event handlers that do things like clear workflow >>> status >>> and local roles when you create a copy. >> I realise that but surely the handlers can have a default behaviour >> that can be changed depending on the configuration? > > In my opinion they should not be globally registered at all, but > available for registration in a local site manager. CMFDefault could > then do that registration for its needs. You are in the cleft stick created by the paradox of "reusable configuration" (an oxymoron, even). The other alternative is to *not* the configuration from CMFDefault, but copy and tweak it for your own app. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpXzP+gerLs4ltQ4RAnfeAKDVHNWHME5cFFuY+r0V3gtQcU7r3gCgrC3N DudQiq3r8xkvq2dbu0kwE6U= =hywa -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
Previously Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: > > Previously Charlie Clark wrote: > >> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: > >>> The workflow tool is not a factor at all here. The problem is that CMF > >>> registers some event handlers that do things like clear workflow > >>> status > >>> and local roles when you create a copy. > >> I realise that but surely the handlers can have a default behaviour > >> that can be changed depending on the configuration? > > > > In my opinion they should not be globally registered at all, but > > available for registration in a local site manager. CMFDefault could > > then do that registration for its needs. > > You are in the cleft stick created by the paradox of "reusable > configuration" (an oxymoron, even). The other alternative is to *not* > the configuration from CMFDefault, but copy and tweak it for > your own app. Not including CMFDefault is entirely reasonable. There are two problems though: - CMFDefault is in the Products namespace, so five will load its zcml automatically. - some of these are in CMFCore (handleDynamicTypeCopiedEvent for example, which zaps local roles from copies). Asking people to copy CMFCore configuration for a reasonably common use case is not desirable imho. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
