Instead of doing a name_get on the edited value and trying to find out
an m2o to assign back (which there's pretty much no chance of given
there's no autocompletion or anything), alter the m2o record in-place
by setting the provided edited value to its _rec_name.
Ideally, both features could be supported via more advanced m2o
edition widgets which would allow selecting an existing m2o, creating
a new m2o record from scratch or (maybe) editing the existing m2o's
display_name if possible, somewhat similar to what the form view
provides.
Without these though, the only action which makes any sense is to edit
the user-visible "value" where it is found, as with more normal
fields.
bzr revid: xmo@openerp.com-20131218140917-4eo2o55yfcumzhov
Before, would save view section itself (including root element). But
branding distribution (and thus editability) are set on the last
programmatic root, thus the root element may well be generated
e.g. <span t-att-foo> will define the span itself as editable.
Saving this would remove the programmatic content on the node, and
thus break the view section altogether.
Fix the issue by only saving the root's content in the previous root.
bzr revid: xmo@openerp.com-20131217112034-nbxbg919cffv4w51
On runbot the base url dispatches into a unknown void of no db being
selected and the CMS thus 404s. For human beings there are additional
links to special subdomains setting the right db in the right place
(or maybe the right dbfilter, whatever) but that doesn't work right
for the crawler test suite.
Instead go through /web/ with a forced db selection, this *should* set
the db correctly in the user's session even if he's anonymous and thus
allows us to browse said db.
No idea if this fevered idea is actually going to work.
bzr revid: xmo@openerp.com-20131106115547-0ozlex09svkecrhb
ddm