Some code prevents to modify or delete an `ir.model.field` if another field
depends on it (like one2many depending on many2one). Make a special case when
the code is executed during a module deinstallation.
OPW 694009
When testing the access rights, attachments associated with
archived/inactive records are inadvertently being hidden due to
the default ORM behavior of search.
Patch simplified while merging.
Closes#14366
Revisions [1] and [2] broke the rendering of extensions-primary view
because it made the wrong assumption that the `read_template` of an
extension-primary view set the `t-name` attribute to the name of the
extension-primary view.
We now patch the `t-name` in the `read_template` result for this case.
[1] 12e36a66f2
[2] 9dd5bd9349
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
Complements rev. 8a7af44a07
The assets cache is only active while not in "xml dev" mode,
so the cache clearing must not be done while this development
mode is active (i.e. with `--dev=xml`)
When a newly-spawned worker detects a stale asset bundle
(due to its empty cache), it regenerates the new bundles,
but has to notify other workers, who would otherwise continue
serving the old list of bundles. This typically leads to
some missing bundles (served as empty files with 404 status),
that could only be cured by restarting the whole server.
Forcing the cache invalidation on the worker that notices
the staleness has no effect (the cache was empty) except
that it causes a cache refresh signal to be broadcast to
all workers.
QWeb's get_template:
* remove the fallback that returned the entire result of IRQweb's
`load` if no match was made between the t-name of the first children
of this result and the template to render
* When get_template receives an etree, directly return it and don't
try to find a matching t-name in it. The loader was not called but
a matching was trying to be made, now that we removed the fallback
a lot of tests that were relying on passing etree didn't work
anymore.
IRQweb's load now return consistently the full result of IrUiView's
`read_templace` when asked to load an id or an xmlid. We make a special
case to patch the result if asked with an id or with a child view so
that the "t-name" of one of the first children of what we return is
always what QWeb is looking for.
Issue: rendering a child view with its xmlid return its `read_template`
wrapped in a "templates" tag. In the context of asset bundles, it leads
to the browser not being able to handle it correctly.
Explanation:
What happens when you render a view? First, QWeb will call is method
`get_template` with the argument `template`. This argument contains the
name of template you try to render. It can be an id or an xmlid (also an
etree but let's forget this one at the moment). Within the method
`get_template`, it'll call IrQweb `load` method, again with the argument
`template`.
This `load` method will call IrUiView's `read_template` wih `template`
as argument. This method will return the view in the database with all
inheritance applied, wrapped in a "templates" tag. When `read_template`
has returned, the `load` method will, according to `template` and in the
following order:
* if `template` is an xmlid, return the whole `read_template`.
* if `template` is an id and if one of the first child has "t-name"
attribute (whatever its value): return the subtree of this first
child.
* if `template` is an id and one of the first child is a "t" tag: set
a "t-name" attribute to this first child with the id as value and
return the subtree of this child.
As you may note, inconsistencies already appear.
Now that QWeb's `get_template` has finished its call to IRQweb's `load`,
it'll do:
* if one of the first child of what's returned as a "t-name" attribute
matching the `template` argument, return this subtree
* return the whole thing returned by IRQweb's `load`.
Let's say we have a view:
<t t-name="base.dummy">
<div><span>something</span></div>
</t>
What happens if we render this view with its xmlid? First Qweb's
`get_template` will load the template with the help of IRQweb's `load`
method. As it received an xmlid as argument, it'll return the whole
`read_template` output, wrapped in a "templates" tag. Qweb's
`get_template` will now check if one of the first child has a "t-name"
attribude matching the `template` argument (base.dummy in our case). It
has one, so it returns the subtree and the compilation continue.
What happens if we render this view with its id? IRQweb's receives an id
as argument, gets the `read_template` of it and check if one of the
first child has a "t-name" attribute. It does, so it returns this
subtree to `get_template`. The latest will check if one the first
children has a matching "t-name" attribute with the `template` argument.
It does not, so it returns the whole thing.
Weird things in the way we got here but the result is the same whatever
you tried to render the template with an id or an xmlid.
Now let's add an extension to this view and try to render it (the
extension):
<xpath expr="//div" position="inside">
<span>another thing</span>
</xpath>
What happens if we render this view with its xmlid? `load` will receive
an id, so it'll return the whole `read_template` stuff. Note here that
if you try to render a parent or child view, `read_template` will return
the same thing: the parent with all inheritance applied. Now `get_template`
looks through the first children of this to find a matching "t-name" and
it doesn't find one, as the "t-name" is the one of the parent view and
we tried to render with the child xmlid. It so returns the whole thing,
wrapped in a "templates" tag. There's our issue.
It's working if we tried to render the thing with its id because `load`
would have returned the right subtree.
This commit adds a test showing the failure.
Planners should only be visible for "base.group_system" user group (admin settings) because there are links to install apps etc. For now missing access rights messages whenever you click a settings link.Only for admin and not by company.
Admin and the user who has "base.group_system" rights can see the planners.
More information from https://en.wikipedia.org/wiki/Decimal_mark section:
"examples of use"
`The following examples show the decimal mark and the thousands separator in
various countries that use the Arabic numeral system.`
`Style: 1,234,567.89 Countries: Malaysia, Mexico, New Zealand, Pakistan,
Philippines, Singapore, Taiwan, Thailand, United Kingdom, United States`
Closes#14402
This commits fixes the following scenario:
1. load translations in language X
2. modify the source of a translated record (e.g. email template body)
3. click on 'load translations' button (flag)
4. execute the translation wizard for the same language (to refresh)
The translation of the modified record was duplicated.
This was due to the field src in the database being different than the msgid in
the po file. The src value is updated on the `insert_missing` call.
The matching on src for type='model' translations is only needed due to the
translations that are split (e.g. xml views or html content). For the other
translations, matching on the rec_id is enough.
opw-691752
Closes#14310
Purpose is to remove old variables in next version:
- obj
- object
- cr
- user
- uid
- context
- pool
- workflow
record = model.browse(env.context['active_id'])
records = model.browse(env.context['active_ids'])
obj, object => record
user => env.user
cr => env.cr
uid => env.user.id
context => env.context
pool => env
workflow => record.signal_workflow()
If multiple views had the same name and same priority, the order
of application of their xpath was not deterministic. That may be a
big deal if both of them were doing xpath with position = inside.
Odoo Translation Bot