In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.
Eg:
> id id_dept name
> -------------------
> 1 1 Tom
> 2 1 Mike
> 3 2 Meggie
> 4 2 Marge
> 5 3 Bart
> 6 3 Lisa
> using LIMITed selects like:
> SELECT * FROM employee ORDER BY id_dept LIMIT 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6
> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.
opw-686639
note: backport of saas-12 4dce8616
Even if there is only one provider,
you could still use the internal login rather than
this oauth provider to sign in,
and therefore you need to remain on the regular
login page if you would like to reset your internal password
When use t-set the value is replaced by an empty list and can't be use inside the t-set.
Issue: <t t-set="bibi"><t t-raw="bibi"/> other</t> => ["\n "] other
When checking for a DOM element in a run method thanks to the action
helper, visible elements are now considered first, then, if none is
found, we take the first invisible one.
Previously all the fields were removed when switching export type, even
if they are available in the newly selected export type. This commit
fixes that.
It was impossible to pass from an archive to another because of
the keep_query in the url generated that set multiple times the
same argument in the url. Removing this allow to have a 'date_begin'
and a 'date_end' corresponding to the selected archive.
This group was defined in the mass_mailing module but is only working when
you install website_mass_mailing. What this group does is allowing to insert
a newsletter snippet in the page, thus it has nothing to do in the mass_mailing
module which doesn't depend on website. Also, the snippet itself was already
defined in website_mass_mailing.
Moved all the things to website_mass_mailing.
If you create an ir.ui.view from the backend, it'll everytime
show a traceback (Keyerror arch).
The field we write to in the form view is `arch_base`. Writing in
`arch_base` will indirectly write on `arch`.
The issue is that the `create` function or ir.ui.view is overriden
in order to compute the `type` column. For this to be done, we parse
the `arch` content and the type is the string of the root tag.
The issue is that we parsed the `arch` field instead of `arch_base`.
However, during the creation of the db, convert.py will write to
the `arch` field when inserting the views in database.
Another thing is that we'll get a traceback if the parse fail for
any reasons (an invalid xml string for example). To workaround
that, we chose to catch the issue and do nothing with it as the
constraint on `ir.ui.view` will detects this issue among others and
will raise a proper ValidationError.
Lastly, the actual code only clears the `arch_fs` field if we write
on `arch`. This patch also clears it when writing on `arch_base`.
[FIX] packaging: debian: update-python-module is no more
The command is not installed by default. It was available in the
python-support library which we didn't depend on and now this library
is no more in debian jessie/ubuntu xenial.
Backported for #13302
If a budget line has no analytic account id, the code is intentional
about returning a value of 0 for it. It is possible, that in some
cases, depending on the order of lines processed, the routine returns
the previous value, as it does not initialise an important
variable on each iteration of the loop.
Closes#13303
- Convert x2many tour to new web_tour.tour system
- Move x2many tour out of web (as web is not duplicated in enterprise
anymore and the new tour system allow to define edition-only steps)
qsm-odoo