initializeProduct chokes on product ids that match ids in the acquisition path?

[newbery]

It appears that App.Product.initializeProduct chokes on product ids that match ids in the acquisition path.

The culprit appears to be line 253...

products._setObject(name, product)

_setObject eventually calls OFS.ObjectManager.checkValidId which chokes at line 119

    if not allow_dup:
        obj = getattr(self, id, None)
        if obj is not None:
            # An object by the given id exists either in this
            # ObjectManager or in the acquisition path.
            flags = getattr(obj, '__replaceable__', NOT_REPLACEABLE)
            if hasattr(aq_base(self), id):
                # The object is located in this ObjectManager.
                if not flags & REPLACEABLE:
                    raise BadRequest, (
                        'The id "%s" is invalid - it is already in use.' % id)
                # else the object is replaceable even if the UNIQUE
                # flag is set.
            elif flags & UNIQUE:
                raise BadRequest, ('The id "%s" is reserved.' % id)

because it acquires the object in the zodb root which cannot be replaced (nor should it).

This of course throws an error... BadRequest The id "%s" is invalid - it is already in use

Can someone confirm this is a real bug or an oddity in my setup?

[Tres Seaver (tseaver)]

What is the name of the product here?

[newbery (ric-digitalmarbles)]

I don't believe the name of the product is relevant but, in this case, the product is a custom Plone theme called Products.techalliance, which translates to a product id of 'techalliance'. It turned out that there was a Plone instance in the ZODB root with the same id. I changed the Plone id and the error went away.

The site was updated from Plone 3.3.4 to Plone 4.0b1 so I believe this is something new in Zope 2.12.3 (http://dist.plone.org/release/4.0b1/versions.cfg). The error didn't manifest itself until after the migration and another error forced me to restart the instance, whereupon it refused to restart with this error. I had to temporarily remove the product in order to get the instance up long enough to change the Plone id.

[Hanno Schlichting (hannosch)]

This sounds weird. Plone 4.0b1 doesn't install any of the products into the Control_Panel/Products section anymore. The zope2instance recipe makes sure to set "enable-product-installation off" by default.

@newberry could you check if the "enable-product-installation off" ends up in your parts/instance/etc/zope.conf file? As part of the upgrade to 4.0b1 Plone should also delete all product entries in the Control_Panel/Products section. After the upgrade there shouldn't be any entries in it anymore.

If those thing work, the code path you showed should never be called.

[newbery (ric-digitalmarbles)]

Actually, if you trace the code, it looks like the "enable-product-
installation" directive doesn't come in until later whereupon this
transaction gets aborted before the commit. So the error pops up
before Zope has a chance to back out of it :P

Ric

On Mar 11, 2010, at 10:31 AM, Hanno Schlichting wrote:

> This sounds weird. Plone 4.0b1 doesn't install any of the products
> into
> the Control_Panel/Products section anymore. The zope2instance recipe
> makes sure to set "enable-product-installation off" by default.
>
> @newberry could you check if the "enable-product-installation off"
> ends
> up in your parts/instance/etc/zope.conf file? As part of the upgrade
> to
> 4.0b1 Plone should also delete all product entries in the
> Control_Panel/Products section. After the upgrade there shouldn't be
> any
> entries in it anymore.
>
> If those thing work, the code path you showed should never be called.
>
> --
> initializeProduct chokes on product ids that match ids in the
> acquisition path?
> https://bugs.launchpad.net/bugs/537057
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Zope 2: New
>
> Bug description:
> It appears that App.Product.initializeProduct chokes on product ids
> that match ids in the acquisition path.
>
> The culprit appears to be line 253...
>
> products._setObject(name, product)
>
> _setObject eventually calls OFS.ObjectManager.checkValidId which
> chokes at line 119
>
> if not allow_dup:
> obj = getattr(self, id, None)
> if obj is not None:
> # An object by the given id exists either in this
> # ObjectManager or in the acquisition path.
> flags = getattr(obj, '__replaceable__', NOT_REPLACEABLE)
> if hasattr(aq_base(self), id):
> # The object is located in this ObjectManager.
> if not flags & REPLACEABLE:
> raise BadRequest, (
> 'The id "%s" is invalid - it is already in
> use.' % id)
> # else the object is replaceable even if the UNIQUE
> # flag is set.
> elif flags & UNIQUE:
> raise BadRequest, ('The id "%s" is reserved.' % id)
>
> because it acquires the object in the zodb root which cannot be
> replaced (nor should it).
>
> This of course throws an error... BadRequest The id "%s" is invalid
> - it is already in use
>
> Can someone confirm this is a real bug or an oddity in my setup?
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/zope2/+bug/537057/+subscribe

[Hanno Schlichting (hannosch)]

The product installation code has been changed to respect the config flag. It no longer tries to write and aborts, but just doesn't write anything in the first place.