[Plone-Users] Dexterity/PloneGlossary meta_type clash - what's happening here?
Dan Jacka
After installing Dexterity 1.0b2 on a Plone 3.3.5 site running PloneGlossary,
I got an Unauthorized exception when browsing to /@@dexterity-types. I've
figured out the problem and can work around it, but I'd like a better
understanding of what's going on.
The exception is:
Unauthorized: Your user account is defined outside the context of the object
being accessed. Access to 'meta_type' of (TypesContext at
/Plone/dexterity-types) denied. Your user account, admin, exists at
/acl_users. Access requires one of the following roles: ['Manager'].
(I'm logged in as admin - the Zope superuser).
I've traced this to the condition expression for ploneglossary.css,
registered in PloneGlossary's cssregistry.xml as:
expression="python:here.meta_type=='PloneGlossary'"
If I remove that expression, no exception.
As I understand it, meta_type is Zope 2 way of identifying classes. Is
PloneGlossary wrong to assume meta_type exists in the current context? Or is
Dexterity wrong not to provide a meta_type? (Actually, I'd have thought that
here.meta_type would be 'Plone Site' since @@dexterity-types is a view on
the site root). Or is there something else at play here?
Dan
--
View this message in context: http://plone.293351.n2.nabble.com/Dexterity-PloneGlossary-meta-type-clash-what-s-happening-here-tp5734982p5734982.html
Sent from the General Questions mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Plone-Users mailing list
Plone...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-users
Martin Aspeli
attribute security validator is not allowing it through?
Martin
Dan Jacka
> Maybe the attribute security validator is not allowing it through?
Any pointers on debugging this? Not something I've dealt with before.
More info: I reduced my buildout to
[buildout]
extends =
buildout.cfg
http://good-py.appspot.com/release/dexterity/1.0b2?plone=3.3.5
eggs +=
Products.PloneGlossary
plone.app.dexterity
where buildout.cfg is the file created by the unified installer. The
exception is now "You are not allowed to access 'meta_type' in this context"
(I had debug products installed before). Full traceback here:
http://pastie.org/1295994
I tried the same buildout on Plone 4.0.1 (changing the the KGS URL to end
with plone=4.0.1). I get the exception there too.
With PloneGlossary uninstalled I set a condition on base.css in portal_css:
python:here.meta_type=='Foo'. As expected, still an exception.
Interestingly, if I remove the condition, create a Dexterity mytype, then
readd the condition, I can get to mytype at /@@dexterity-types/mytype
without a problem. I can add fields and behaviours sucessfully. But
/@@dexterity-types still keeps me out as Unauthorized.
Dan
--
View this message in context: http://plone.293351.n2.nabble.com/Dexterity-PloneGlossary-meta-type-clash-what-s-happening-here-tp5734982p5736576.html
danielle
traced to the expression
expression="python: here.meta_type in ['EasyNewsletter', 'ENLIssue']" in
jsregistry.xml
--
View this message in context: http://plone.293351.n2.nabble.com/Dexterity-PloneGlossary-meta-type-clash-what-s-happening-here-tp5734982p6396901.html
Sent from the General Questions mailing list archive at Nabble.com.
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
Dieter Maurer
>same experience with Dexterity 1.0 and Products.EasyNewsletter
>traced to the expression
>expression="python: here.meta_type in ['EasyNewsletter', 'ENLIssue']" in
>jsregistry.xml
I am fairly sure that "Dexterity" will not hard code meta_type values.
Instead, such values will be derived from things specified by the
"Dexterity" user. Thus, he should avoid name clashes.
What you see is a general Zope weakness: "meta_type" uses a flat
(global) namespace. For a global flat namespace, name clashes
have a somewhat higher probability. Care must be taken to avoid them.
--
Dieter
Dieter Maurer
danielle davout wrote at 2011-5-24 23:39 +0700:
>Thanks for your answer, do you see a way for a simple user to use these 2
>products at the same time ?
You have not read my message carefully enough ;-)
I am convinced that "Dexterity" does not fix (choose) "meta_type"
values on its own.
If this is correct, there is no principle problem to use
"Dexterity" and "PloneGlossary" or "EasyNewsletter" together.
However, one has to be careful using "Dexterity" to describe
new content types. As Zope needs a "meta_type", "Dexterity" somehow
must associate one with the new type. It will derive the
value from the content type specification. With the correct
specification, one can avoid "meta_type" clashes.
I, myself, have not yet used "Dexterity". Thus, I cannot give
you the details. But, "Dexterity" is said to have good documentation ;-)
Dieter Maurer
(Please stay on the list!)
danielle davout wrote at 2011-5-25 15:37 +0700:
>...
>I have just installed Dexterity and gone to the Dexterity control panel ..
>and encountered the mentionned error .. : if I can put it like that I didn
>t the feeling to become a Dexterity user (before uninstalling
>EasyNewsletter )
This indicates that "dexterity" is not at all responsible for
the name clash but only detects it. Something else has
introduced the clash.
You could look at how "dexterity" found the clash in order
to identify the problematic products.
I expect, it will use the standard folder method
"all_meta_types". This returns a dict describing the meta types.
I think the "name" key (but maybe has a different name) provides
the thing that is clashing, the "action" key typically references
the product that defined this meta type.
Dan Jacka
Dieter Maurer wrote:
>
> Mailing list readded...
> (Please stay on the list!)
>
> danielle davout wrote at 2011-5-25 15:37 +0700:
>>...
>>I have just installed Dexterity and gone to the Dexterity control panel
..
>>and encountered the mentionned error .. : if I can put it like that I
didn
>>t the feeling to become a Dexterity user (before uninstalling
>>EasyNewsletter )
>
> This indicates that "dexterity" is not at all responsible for
> the name clash but only detects it. Something else has
> introduced the clash.
>
>
> You could look at how "dexterity" found the clash in order
> to identify the problematic products.
>
> I expect, it will use the standard folder method
> "all_meta_types". This returns a dict describing the meta types.
> I think the "name" key (but maybe has a different name) provides
> the thing that is clashing, the "action" key typically references
> the product that defined this meta type.
>
>
>
> --
> Dieter
>
danielle davout wrote at 2011-5-24 23:39 +0700:
>Thanks for your answer, do you see a way for a simple user to use these 2
>products at the same time ?
Danielle, try changing the expression to test against portal_type instead,
i.e. expression="python: here.portal_type in ['EasyNewsletter',
'ENLIssue']". That's the workaround I used with PloneGlossary.
Dieter, you hit this problem with a very simple Plone setup: Plone 4.0.5
from Unified Installer, buildout for Dexterity 1.0 and the latest
PloneGlossary (1.5.0b2); create a new site and install both products. That's
it. You'll get the meta_type error browsing to /@@dexterity-types. I can see
how adding products to an already busy site could introduce meta_type
clashes, but not here with nothing else installed, no Dexterity types and
barely any site content.
Dan
--
View this message in context: http://plone.293351.n2.nabble.com/Dexterity-PloneGlossary-meta-type-clash-what-s-happening-here-tp5734982p6402319.html
Sent from the General Questions mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Régis Rouet
expression="python: here.portal_type in ['EasyNewsletter', 'ENLIssue']"
Just ran into this issue. I use EasyNewsletter too.
Thanks all and especially Dan for the analyse and fix.
It works here.
--
View this message in context: http://plone.293351.n2.nabble.com/Dexterity-PloneGlossary-meta-type-clash-what-s-happening-here-tp5734982p7246893.html
Sent from the General Questions mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
Dieter Maurer
>>try changing the expression to test against portal_type instead, i.e.
>expression="python: here.portal_type in ['EasyNewsletter', 'ENLIssue']"
>
>Just ran into this issue. I use EasyNewsletter too.
>Thanks all and especially Dan for the analyse and fix.
>It works here.
I remember to have seen this problem in the mailing list.
Search the archive (e.g. via "gmane") to find the corresponding thread.
When I remember right, the problem was resolved there.
--
Dieter
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2