-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RelationChoice field leads to ValueError in principals #59
Comments
I have the same problem with a custom field that is using CatalogSource as source. What i don't understand, is why the view called by the widget tries to get the term of principals vocabulary. |
Because of this:
Maybe this issue belongs somewhere else: plone.app.z3cform or CMFPlone? Edit, there seem to be two things at play here.
So, when returning
The widget appears to be "working" - I can now navigate back to the LRF Edit/update: an image in the LRF can now be found correctly |
Looking at the RelatedItems behavior (https://github.com/plone/plone.app.relationfield/blob/master/plone/app/relationfield/behavior.py#L26) there is the widget directive with the vocabulary defined. So something like this should do the trick (untested!)
NOTE: the and remember to add |
The problem lies with the toWidgetValue converter not recognizing (None, ) as None and the lack of permissions on plone.app.vocabularies.Principals. The latter is required by a query from the form.widgets.IDublinCore.creators widget- unclear why this is done... |
Any updates here? Is somebody working on this one? |
This would fix plone/plone.app.vocabularies#59, but I'm only floating this change as an idea, hoping for some feedback. `z3c.form.widget.Widget.update()` passes the result of `creatorsDefault` (which is called by an `IValue` adapter's `get()` method) to `plone.app.z3cform.converters.AjaxSelectWidgetConverter.toWidgetValue()`. `getSecurityManager().getUser()` returns a regular `<PropertiedUser>` for most requests and thus the return value is a tuple, e.g. `('admin',)`. However, for ajax requests, e.g. `/++add++MyContentType/++widget++form.widgets.IMyBehavior.behavior_field`, the user is anonymous: ``` (Pdb) user <SpecialUser 'Anonymous User'> (Pdb) pp user.__dict__ {'__': '', 'domains': [], 'name': 'Anonymous User', 'roles': ('Anonymous',)} ``` Thus, the return value is the tuple `(None,)`. This breaks `AjaxSelectWidgets` when the content type includes the Dublin Core behavior or just the ownership field, even though the field itself is a `RelationList` with a `value_type=RelationChoice( source=CatalogSource(portal_type='MyContentType) )`. In other words, even though the broken field has no need for the item's creator, the creator gets calculated anyway when the request is handled. The problem with the tuple `(None,)` is that `toWidgetValue()` does not know how to deal with it and so it returns `None` instead of `field.missing_value` as it should. This could be fixed in at least four different places: 1. plone.app.dexterity.behaviors.metadata.creatorsDefault 2. plone.app.z3cform.converters.AjaxSelectWidgetConverter.toWidgetValue 3. z3c.form.widget.Widget.update 4. have getSecurityManager().getUser() return the logged in user even on Ajax requests. 1. is the origin of the unexpected value, however, I don't know if making it return `None` for anonymous users would make any other code mad. 2. is the place that does not expect a `(None,)` tuple instead of `None`, so this could be fixed by simply adding a check for `(None,)`. 3. is the "middleman" between 1 and 2, so it could convert `(None,)` to `None` before passing it on. 4. I have no idea what this would entail.
By the way, I don't see the need to add a permission on plone.app.vocabularies.Principals, @mtrebron . |
@fulv correct, that permission is not necessary (anymore?). |
Is this the same issue as this one? plone/plone.app.z3cform#121 |
Yes, good catch. Will close as fixed by plone/plone.app.z3cform#122 |
Dexterity types which include a RelationChoice field e.g.
lead to the following error in Plone 5.2 RC5
The text was updated successfully, but these errors were encountered: