6.1RC1: 'uid' not available in attrs evaluation context
Bug #920033 reported by
Hardik Shah
This bug affects 7 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
Opinion
|
Medium
|
OpenERP's Framework R&D |
Bug Description
When I try to compare the logged in user with the user_id stored on the database to run time display a field or button using attrs="
Was working in previous versions. Please suggest a fix.
Related branches
lp:~openerp-dev/openobject-client/trunk-bug-920033-jam
Ready for review
for merging
into
lp:openobject-client
- OpenERP Core Team: Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedbin/modules/action/main.py (+1/-1)
lp:~openerp-dev/openobject-server/trunk-bug-920033-jam
Rejected
for merging
into
lp:openobject-server
- OpenERP Core Team: Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedopenerp/osv/orm.py (+1/-1)
affects: | openerp-web → openobject-server |
Changed in openobject-server: | |
milestone: | 6.1 → none |
assignee: | OpenERP R&D Web Team (openerp-dev-web) → OpenERP's Framework R&D (openerp-dev-framework) |
importance: | Undecided → Medium |
status: | Fix Released → Confirmed |
Changed in openobject-server: | |
status: | Confirmed → In Progress |
Changed in openobject-server: | |
status: | Fix Committed → Invalid |
Changed in openobject-server: | |
status: | Invalid → Fix Released |
Changed in openobject-server: | |
status: | Fix Released → Invalid |
Changed in openobject-server: | |
status: | Invalid → Opinion |
To post a comment you must log in.
Hi,
The "uid" dynamic value is not a valid field to be evaluated client-side. This was working previously because the clients (GTK/Web) happened to have a "uid" value available in the evaluation context, but that is not guaranteed to be the case, as far as I know.
What you are trying to do seems a little bit of a corner case (none of the standard addons do it), so I'm not sure it would be worth adding a global "uid" value to client-side evaluation context.
What we often want to do is to selectively hide fields based on user groups or document states. These 2 cases are covered by the API with the ``states`` and ``groups`` attributes.
Here you want the behavior to differ when the user is viewing one of her "own documents". A simple workaround to accomplish this would be to add a function field to that document, and have it always return the current user ID. If you named the field "uid" you could probably keep your existing `attrs`.
As for adding "uid" to the default client-side (web) evaluation context, and making it a permanent API feature, it should be discussed with the web team, so I'm reassigning it to them.