Using a wildcard-destination in the zcml of an upgradeStep breaks setup_upgrades.zpt.

[Wouter Vanden Hove]

If you use an upgrade-step like this
{{{
  <genericsetup:upgradeStep
    title="collective.foo - fixes"
    description="Fixes"
    source="1"
    destination="*"
    handler="collective.foo.upgrades.fixes"
    sortkey="1"
    profile="collective.foo:default" />
}}}
it will break the template "setup_upgrades.zpt" in portal_setup when trying to access the available upgrade-steps for that specific package.

This is the traceback:

{{{
 Time 2010/03/31 16:55:50.024 GMT+2
User Name (User Id) admin (admin)
Request URL http://porttst2.ugent.be:8080/plone_portal/portal_setup/manage_upgrades
Exception Type TypeError
Exception Value sequence expected, NoneType found

Traceback (innermost last):

    * Module ZPublisher.Publish, line 119, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module Products.PDBDebugMode.runcall, line 70, in pdb_runcall
    * Module ZPublisher.Publish, line 42, in call_object
    * Module Shared.DC.Scripts.Bindings, line 313, in __call__
    * Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
    * Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
    * Module Products.Gloworm, line 28, in pt_render
    * Module zope.pagetemplate.pagetemplate, line 117, in pt_render
    * Module zope.tal.talinterpreter, line 271, in __call__
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 855, in do_condition
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 536, in do_optTag_tal
    * Module zope.tal.talinterpreter, line 521, in do_optTag
    * Module zope.tal.talinterpreter, line 516, in no_tag
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 623, in do_insertText_tal
    * Module Products.PageTemplates.Expressions, line 230, in evaluateText
    * Module zope.tales.tales, line 696, in evaluate
      URL: manage_upgrades
      Line 32, Column 2
      Expression: <PythonExpr test(same_type(version, tuple()), '.'.join(version), version)>
      Names:

      {'container': <SetupTool at /plone_portal/portal_setup>,
       'context': <SetupTool at /plone_portal/portal_setup>,
       'default': <object object at 0x7ffe07177200>,
       'here': <SetupTool at /plone_portal/portal_setup>,
       'loop': {},
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd3d47e8>,
       'request': <HTTPRequest, URL=http://porttst2.ugent.be:8080/plone_portal/portal_setup/manage_upgrades>,
       'root': <Application at >,
       'template': <PageTemplateFile at /plone_portal/portal_setup/setup_upgrades>,
       'user': <PropertiedUser 'admin'>}

    * Module Products.PageTemplates.ZRPythonExpr, line 49, in __call__
      __traceback_info__: test(same_type(version, tuple()), '.'.join(version), version)
    * Module PythonExpr, line 1, in <expression>

TypeError: sequence expected, NoneType found
}}}

This happens on plone 3.3.5 + GenericSetup 1.4.5
and on Plone4.0b1 + GenericSetup 1.6.0b1

Patch for the template in attachment.

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wouter Vanden Hove wrote:
> ** Patch added: "patch.txt"
> http://launchpadlibrarian.net/42788090/patch.txt

 status incomplete

Hmm, I can't reproduce the traceback. I'm not opposed to applying the
patch (it looks pretty reasonable to me) but I would like to be sure I
have really fixed the bug you report.

The attached tarball contains an almost empty product, with only the
minimum necessary to get an upgrade step registered. It includes
registering an (empty) profile, as well as an upgrade step for that
profile, lightly modified from the one you posted.

Here is what I tried:

- - I created a Zope 2.12 INSTANCE_HOME with GenericSetup installed
  (I tried with both trunk and 1.4 branch)

- - I copied the 'testproduct' into the 'Products' folder of the instance.

- - I started the appserver.

- - In the ZMI root, I created a folder, 'test_lp553338'.

- - In the ZMI for that folder, I added a "Generic Setup Tool."

- - On the ZMI "profiles" tab for the tool, I selected the "Testproduct
  Site" profile.

- - I visited the "Upgrades" tab for the tool, and could see the upgrade
  step.

Can you try reproducing with my product?

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku0tcAACgkQ+gerLs4ltQ7JagCaArNJAn6WziP8JCpmUtm1PjaQ
vN0AoK5iDed0eL+40F7u2F6QyZajYUEf
=c9lO
-----END PGP SIGNATURE-----

[Wouter Vanden Hove (wouter-wvhconsulting)]

I need to retract that is reproducible on Plone4.0b1 + GenericSetup 1.6.0b1
This happens on plone 3.3.5 + GenericSetup 1.4.5.

I do get a traceback when following above steps in a Plone 3.3.5-instance (Zope-2.10.11 + GS 1.4.5)

The problem is that None gets stored in the dict, breaking the template:

 > self._profile_upgrade_versions
  {'Products.testproduct:default': None}

but fixing the template seems the wrong place to fix it.
I see that it's fixed with an extra condition in trunk in r94296, but not applied in the 1.4-branch.

Patch in attachment.

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wouter Vanden Hove wrote:
> I need to retract that is reproducible on Plone4.0b1 + GenericSetup 1.6.0b1
> This happens on plone 3.3.5 + GenericSetup 1.4.5.
>
> I do get a traceback when following above steps in a Plone
> 3.3.5-instance (Zope-2.10.11 + GS 1.4.5)
>
> The problem is that None gets stored in the dict, breaking the template:
>
> > self._profile_upgrade_versions
> {'Products.testproduct:default': None}
>
> but fixing the template seems the wrong place to fix it.
> I see that it's fixed with an extra condition in trunk in r94296, but not applied in the 1.4-branch.
>
> Patch in attachment.
>
> ** Patch added: "Patch for tool.py in the 1.4-branch"
> http://launchpadlibrarian.net/42807340/patch-branch-1.4.diff

 status fixcommitted

Thanks very much for the follow-up: I was able to reprodue the error by
actually running the upgrade step: at that point, the None value did
cause the problem.

Fix with tests committed to the 1.4 branch:

http://svn.zope.org/Products.GenericSetup/branches/1.4/?rev=110435&view=rev

and the trunk:

http://svn.zope.org/Products.GenericSetup/trunk/?rev=110436&view=rev

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku099wACgkQ+gerLs4ltQ55cwCeL1EG3YuGfz4tsJTff5MheBP/
gHwAn1/GENpkcoHn5NwOd+IMdZOY/T50
=XNv1
-----END PGP SIGNATURE-----