Archetypes throws exception on adding new items

[michaellindig]

If you add new archetypes content then you got following exception after calling save:

Request URL  http://.../fsd-org/kalender/portal_factory/Event/event.2010-01-18.7875682116/atct_edit

Exception Type AttributeError Exception Value 'NoneType' object has no attribute 'meta_type'

Traceback (innermost last):

• Module ZPublisher.Publish, line 125, in publish
• Module Zope2.App.startup, line 238, in commit
• Module transaction._manager, line 96, in commit
• Module transaction._transaction, line 389, in commit
• Module transaction._transaction, line 445, in _callBeforeCommitHooks
• Module collective.indexing.transactions, line 57, in before_commit
• Module collective.indexing.queue, line 147, in process
• Module collective.indexing.indexer, line 63, in unindex
• Module collective.indexing.indexer, line 45, in unindex
• Module Products.CMFSquidTool.queue, line 160, in unindexObject
• Module Products.CMFSquidTool.patch, line 24, in call
• Module Products.Archetypes.CatalogMultiplex, line 43, in unindexObject
• Module Products.Archetypes.utils, line 983, in isFactoryContained

AttributeError: 'NoneType' object has no attribute 'meta_type'

I use Plone-3.3.4 with Products.Archetypes-1.5.14, with Plone 3.3.3 I did not have such problems!

[kleist]

Does this happen also in a site without collective.indexing and/or CMFSquidTool? The sinner might be one of those add-ons, rather than Plone proper.

[michaellindig]

I can not disable it, so I can not answer :(

I think a proper check for the return value of 'aq_parent(aq_inner(obj))' is not too bad, or?

[michaellindig]

A working solution for me is to change the method Products.Archetypes.utils.isFactoryContained as follows:

def isFactoryContained(obj):
    """Are we inside the portal_factory?
    """
    return aq_parent(aq_inner(obj)).meta_type == 'TempFolder'

into

def isFactoryContained(obj):
    """Are we inside the portal_factory?
    """
    pobj = aq_parent(aq_inner(obj))
    return pobj is not None and pobj.meta_type == 'TempFolder'

Maybe this is only a valid solution in my case where I use collective.indexing and CMFSquidTool (I can not say which of this two does the wrong patching part :( ) but I think it is a good idear to check the return code of aq_parent(aq_inner(obj)) espacially in this critical function.

[toutpt]

I have the same issue but this is the strange part of my debug:

(Pdb) aq_parent(aq_inner(obj))
(Pdb) obj.aq_inner.aq_parent
<ATBTreeFolder at /plone/images>

So obj.aq_inner.aq_parent is working.

[cah190]

I'm seeing similar exceptions installing products such as PloneFormGen and FacultyStaffDirectory. With product installation the failure comes when unindexObject is called on tools.

I managed to get my test instance working again by changing isFactoryContained to ensure the object has a meta_type attribute before checking its value:

def isFactoryContained(obj):
    """Are we inside the portal_factory?
    """
    pobj = aq_parent(aq_inner(obj))
    return hasattr(pobj, 'meta_type') and pobj.meta_type == 'TempFolder'

This also works for the case where pobj is None, as mentioned above.

[thomasw]

My experience: The combination with collective.indexing seems to be relevant. Inside isFactoryContained I get:

(Pdb) obj
<PathWrapper at /osha/portal/Members/thomas_syslab_com/document.2010-01-22.4994996445>
(Pdb) obj.__class__
<class 'collective.indexing.queue.PathWrapper'>

(Pdb) aq_parent(aq_inner(obj))
(Pdb) aq_parent(aq_inner(obj.context))
<ATFolder at /osha/portal/Members/thomas_syslab_com>
(Pdb) obj.aq_inner.aq_parent
<ATFolder at /osha/portal/Members/thomas_syslab_com>

As I cannot easily disable collective.indexing at the moment, I can't give an example without it. But the key seems to me that aq_inner() on a PathWrapper does not return its context.

[kiorky]

I confirm the bug with both:

• Products.Relations
• FacultyStaffDirectory
• CacheFu things

I'm on my way to test with only FSD and Relations.

We have a working patch here from another project than my current use case (toutpt, one of my workmates made it) but we don't like that much. Nevertheless, it's in the same mood of the others solutions posted here, just with additionnal logging.

However, for us, it seems to be only a workaround.

Before posting it, i 'll try to investigate more.

[hannosch]

I fixed this in Archetypes and made a new release (1.5.15), which will be part of Plone 3.3.5.

Feel free to investigate further, maybe I misunderstood something about the ticket.

[kiorky]

Now, i am free either from collective.indexing or cachefu.

in my case, similar to #comment:5, our locally toutpt's patch is not working, i'm trying to arrange something mixed between cah190 and toutpt solutions.

Hannosh, the case where obj.aq_inner.aq_parent works but not aq_(aq_(obj))seems missing from the commited patch. It would be good to add some logs too (even only debug)?

[kiorky]

Maybe something like that :

(minitage-p3) ~>svn diff Archetypes/Products/Archetypes/utils.py Index: Archetypes/Products/Archetypes/utils.py =================================================================== --- Archetypes/Products/Archetypes/utils.py (révision 12134) +++ Archetypes/Products/Archetypes/utils.py (copie de travail) @@ -901,7 +901,12 @@

""" parent = aq_parent(aq_inner(obj)) if parent is None:

+ try: + parent = obj.aq_inner.aq_parent + except: + pass

# We don't have enough context to know where we are

• return False

+ if parent is None: + return False

meta_type = getattr(aq_base(parent), 'meta_type', ) return meta_type == 'TempFolder'

[kiorky]

Rah, wiki formating: maybe something like that ?

(minitage-p3) ~>svn diff  Archetypes/Products/Archetypes/utils.py
Index: Archetypes/Products/Archetypes/utils.py
===================================================================
--- Archetypes/Products/Archetypes/utils.py     (révision 12134)
+++ Archetypes/Products/Archetypes/utils.py     (copie de travail)
@@ -901,7 +901,12 @@
     """
     parent = aq_parent(aq_inner(obj))
     if parent is None:
+        try:
+            parent = obj.aq_inner.aq_parent
+        except:
+            pass
         # We don't have enough context to know where we are
-        return False
+        if parent is None:
+            return False
     meta_type = getattr(aq_base(parent), 'meta_type', '')
     return meta_type == 'TempFolder'

[toutpt]

It's working nice now with collective.indexing. Thank you hannosh

[witsch]

Replying to toutpt:

It's working nice now with collective.indexing. Thank you hannosh

i don't think this should be closed just yet. as thomas already pointed out the real issue lies with collective.indexing's path wrapper class, which doesn't work correctly with aq_inner. please also see issues  #6 and  #9 in its bug tracker for more information.

iow, the proper solution should be to fix collective.indexing, which i will try to do asap, after which  r12128 can — and probably should — be reverted...

[witsch]

Replying to witsch:

iow, the proper solution should be to fix collective.indexing, which i will try to do asap, after which  r12128 can — and probably should — be reverted...

taking over to report once the fix is in...

[witsch]

the issue was fixed in  r109603 and will be released with collective.indexing 1.3, probably tonight...

[witsch]

Replying to witsch:

[...] after which  r12128 can — and probably should — be reverted...

hanno, i'm handing the ticket over to you to decide if you want to revert that change. personally i think it should be as every AT item should have a meta_type and we actually want it to break if something doesn't play by the rules. but since you made it, it'll be your call... :)

[hannosch]

While in theory everything should have a meta_type in Zope2, we don't really enforce that anywhere and I'm sure there's some variation of the "how to create an Archetypes content type" that isn't mentioning this.

Secondly Acquisition chains tend to be messed up pretty badly. Especially if there's any view component involved and someone forgot the aq_inner(self.context) somewhere. And then portal_factory itself munges the AQ chain in interesting ways.

I'd prefer to be on the defensive side in this kind of code. Make a call to portal_factory from inside a KSS request and who knows what Acquisition chain such a thing has ;-)

[witsch]

Replying to hannosch:

I'd prefer to be on the defensive side in this kind of code.

ok, +1 in terms of "worksforme".

Make a call to portal_factory from inside a KSS request and who knows what Acquisition chain such a thing has ;-)

tsk tsk, those dirty fantasies you come up with all the time... :)

[witsch]

for the record, a "proper" fix for the underlying issue was released in  collective.indexing 1.3