Clicking on mark as read on a given message would move all messages in
inbox to history instead of only selected message(s). This commit fix
that behaviour so that only the selected message(s) move(s) to history.
task-2284543
closesodoo/odoo#54688
X-original-commit: 3304b89fc799b979b028aa4c7efe902b2f5276c1
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Follow-up of odoo/enterprise#11881, in order to eliminate all similar
typos.
The CSS pseudo-class selectors are spelled `:first-child` and
`:last-child`, and never take any argument, as opposed to
`:nth-child(<nth>)` for example.
Ref: https://developer.mozilla.org/docs/Web/CSS/Pseudo-classes
jQuery doesn't care and matches with or without the `()`, but CSS
engines don't, and now libsass SCSS compilation crashes due to the empty
argument list (cfr. opw-2299465)
Better avoid confusion and fix the typo everywhere.
closesodoo/odoo#54685
X-original-commit: 82244e17339615615535073e6f9e1ddbcf0b57d9
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit, in case you were in --dev-mode, if a json request crash,
it was wrongly intercepted and return a Internal Server Error with status 500
and without the JSON Response
For the change of http code, since it is only in dev mode, it could not impact
a production server (in theory) with custom code based on it.
After this commit, if your rpc fails, you will not have anymore a breakpoint in
the code to help the developer to debug. But you will have a status 200 on the
rpc request.
closesodoo/odoo#54668
X-original-commit: 534cca311db1ecf1005a24d5cbd50e166094ba2a
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, it might happen that text field columns in list
views were completely crushed, to let space to the other columns.
This commit fixes the issue by preventing text fields from being
wrapped during the ideal column widths computation. Doing so, text
fields will take space they deserve according to their content.
They will then be wrapped if necessary, so that they aren't trimmed,
unlike e.g. char fields.
Task 2275747
closesodoo/odoo#54664
X-original-commit: 5c54111127bd99eedb4e0331aba5a0200feb461c
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We now allow invoicing of finalized orders in an open session in this first
iteration of order management in the pos frontend. Additionally, receipt
reprinting is also introduced. With this feature, we can now reprint the
receipt of old orders.
closesodoo/odoo#51141
Task-id: 1981354
Related: odoo/enterprise#11690
Related: odoo/upgrade#1472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
A term was present twice in Italian, making the installation of
Italian crash for the Swich CoA
Introduced at a3029a8
Remove some reference to company accounts (it is handled by
l10n_multilang, should not be set manually as working only for company
wiht id 1)
closesodoo/odoo#54658
X-original-commit: fb10cc6d0af59d255c0c3f2dd52c97b2cf31a628
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commits fixes the case where you click on
edit address in eCommerce payment flow and you
type a wrong coupon code.
Without this commit, you are redirected at
/shop/payment instead of /shop/checkout
OPW-2290188
closesodoo/odoo#54646
X-original-commit: 0d658349483054bf30c8be483e2f42671e0ba024
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Improve tooltip style/design to get rid of black background and purple title,
instead design tooltip like popover design, to have tooltip with white
background and light grey title
task-2266829
closesodoo/odoo#53723
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Ipsita Borisagar <ibo@odoo.com>
Keep the selected image after moving it in the gallery. So that the
options for moving the current image are always displayed.
Part of https://github.com/odoo/odoo/pull/45096
task-2162952
Add the width option for each slides in the carousel snippet.
Remove share links from the third slide of the carousel.
Part of https://github.com/odoo/odoo/pull/45096
task-2162952
Snippet image gallery retains only the slideshow mode and a new snippet
called 'image wall' takes the 3 other modes.
Part of https://github.com/odoo/odoo/pull/45096
task-2162952
In gallery snippet with slideshow mode, the right/left indicators have
now the same behavior in editor and outside. Before this commit, these
indicators were always visible in editable mode.
Part of https://github.com/odoo/odoo/pull/45096
task-2162952
The permission check in BaseModel:export_data was checking if the
current user was the administrator user, instead of checking if the
environment was administrator (i.e. it should also check if the sudo bit
is set on the environment).
This commit fixes this and allows to export_data with a simple `sudo()`
instead of needing a `with_user(SUPERUSER_ID)`.
closesodoo/odoo#54647
X-original-commit: f69f47b6ba5c6c462bf617f4876a39233f60034f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
In some complex cases, some snippet editors were destroyed but were
still referenced in memory.
E.g.
1) Reorder a snippet gallery image
2) The code is implemented in such a way that reordering create a new
wrapping column for each image and moves the images in them.
3) This result in having the snippet editor linked to the old columns
to be explicitely destroyed and removed from memory, but not the ones
linked to the images as they are still in the DOM (just moved).
4) ... but the snippet editors linked to the images are children of
the snippet editors linked to the columns. They are thus implicitely
destroyed... but not removed from memory.
closesodoo/odoo#54643
X-original-commit: e4bf37c7fc892cdba57f0acac8e10f5698184e67
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The bug was already solved with [1] but was reintroduced later for
another reason. [1] solved the problem by checking that the current
option is not destroyed before asking for an UI update thanks to a
trigger_up (the option was destroyed because of image reordering). The
bug is now reintroduced for the same basic reason: a new trigger_up was
added between the potential option destroy and the destroy check, so
if the option is destroyed, that trigger_up fails to be triggered and
the editor is locked.
This commit solves the problem once and for all, hopefully, with a
more robust solution: only destroy options when none is being
processed. That way we ensure that all trigger_up occuring during an
option activation / update can be properly done.
[1]: https://github.com/odoo/odoo/commit/9eeea4c4107dc15984c475582d5ee58a17cd2568
X-original-commit: 7770430f78ee9e122a732fa042226d362467158e
Commit [1] broke the background videos feature. This is because the
'we-imagepicker' widget is now a sub-widget of a new 'we-button-group'
widget, acting as a selection choice (same as we-button in a we-select).
When selecting a selection choice, the appropriate option method is
called, with the selection value and params... but the params were
actually the ones of the 'we-button-group' element and not the ones
of the chosen widget 'we-imagepicker'.
This has never been important for we-select widgets but it could have
been. The problem is only solved here in master, generically for all
selection widgets (currently only 'we-select' and 'we-button-group').
The params received are the ones of the active sub-widget combined with
the ones of the selection widget.
[1]: https://github.com/odoo/odoo/commit/bb0cd4d5c82a9c2311f8c45ced0e9fdc0397d292closesodoo/odoo#54629
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Bug
===
Register to an event with a public user.
Sometimes an ACL error will be raised.
Technical
=========
Before flushing the environment (after the creation of the event
registration in the endpoint `registration_confirm`), the ORM will
recompute all needed stored fields. As we didn't write on some of them
(`date_closed`, `utm_campaign_id`, `utm_source_id`, `utm_medium_id`)
they are in the list `Environment::all.tocompute`. So, the ORM will recompute
the fields even if the state didn't change (this behavior can be verify
in `BaseModel::recompute`). This is done after the "create" call of the
event registration and so without the SUDO flag.
Task-2299227
closesodoo/odoo#54624
X-original-commit: 38f37cd483b7907b20171e2c44e14e69e3e00596
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1. Methods associated to touchmove and touchstart listeners should not
call preventDefault because they are passive by default. Calling preventDefault
will do nothing but in chrome browser, error message is issued.
2. We now allow resize based on touch events.
closesodoo/odoo#54612
X-original-commit: c6b7133d9c9dc52a8d283124b5a4497940e54682
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The primary goal of disableRubberbanding is to disable scrolling during
touch event by default and to allow only selected descendants to have scrolling
active during touchstart+touchmove event. Only elements with class="touch-scrollable"
are allowed for touch scrolling. This restriction can be a good idea but it
results to bug-ridden explicitness which is not necessary because scrolling
should be allowed automatic by default in the first place. In this commit, we
allowed scrolling by default by:
1. We remove disableRubberbanding.
2. We set the position property of .pos to fixed. This is to accomplish the
original goal of disableRubberbanding (fixing the root element in its position).
3. We remove the touch-scrollable class as they are not needed anymore and
no style associated to it.
Removing the disableRubberbanding method also fixes the Intervention error during
touch scrolling event. The reason for that error is we are calling preventDefault
in the event that is passive. touchmove and touchstart events are passive by default
- which means that preventDefault won't work.
X-original-commit: 54f7fb49dae3aab6a005402a1ac60262bbd15edc
After the commit 2a57a156c7b8e81c01afa095b3291361d208611f
Cloc excluded by default one more folder, it should appear
in the documentation of the tools
closesodoo/odoo#54609
X-original-commit: 93261c787d1152c94856ef31a1600a4cdab8b83b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This allows user to close multiple windows with ESC key.
task-2283891
closesodoo/odoo#54604
X-original-commit: bac3d7792a48f86a39f92e0fcfc18d522ce00d94
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, try to post a comment will raise a traceback in front end
because textarea is not found.
Now, we check that we are writing in textarea content and no more in textarea
comment.
closesodoo/odoo#54595
X-original-commit: 867458456b13daf9b5586c17b7475e68d9d008e1
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Limit must be 70 not 71
closesodoo/odoo#54587
X-original-commit: 7d808675de88ed54de67f798de9cec16bb95ef3b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Adding additional product to a production but consuming 0 on it will
trigger the consumption warning wizard while no difference with the bom
are occurring. This commit do not trigger the consumption issue in that
case.
Task : 2278147
closesodoo/odoo#54561
Related: odoo/enterprise#11885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
On a MO which product_id has a serial tracking, some components and 2
or more WO:
The method _set_qty_producing of a WO will call the MO _set_qty_producing
method even if no changes is made on qty_producing which can produce an
undesired aditional move line when creating the MO.
On a MO which product_id has a serial tracking and some components:
Changing the qty_producing on a MO was adding a line on the component
move.
Since the _set_qty_producing method is called when creating a WO it sets
the qty_producing of the MO to 0. As it does not make sense to have a WO
set the qty_producing of a MO to 0 we will not replicate it.
task-2278147
closesodoo/odoo#54579
X-original-commit: ca8275aa28010b73cad14f667068e9cfc6c651a5
Related: odoo/enterprise#11896
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
_set_quantity_done_prepare_vals is call to (re)create move line
during some onchange/compute. But it never removed empty line.
Then remove empty line (when no reserved quantity and no done quantity)
task-2278147
X-original-commit: a1ab74d6cd75cee64fcd432d387180299fd64c72
The tests must be only imported in a test context, not in a running
context.
Since 92a7f8c13f a new test requirement was added but it should
not be necessary to run a module, only to execute the tests.
closesodoo/odoo#54578
X-original-commit: 15f2bbd40a70d9d9e969a2c75b7b9131c100dc09
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since recordsets are self-recursive, they should be treated like
strings (where iterating a string yields a string, infinitely) in case
somebody happens to return a non-downgraded recordset from a method.
closesodoo/odoo#54572
X-original-commit: 6d88845f339d164fc2667c3417dcc331b317e4db
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit:
If a template_id is put on the first stage, a partner is
automatically created at the creation of the applicant. And if the
applicant had a phone or a mobile, they are removed.
After this commit:
The phone and mobile are saved on partner and not removed from
applicant.
taskId 2299970
closesodoo/odoo#54574
X-original-commit: 3735c3363f422d01ae1ff96e761a1b206fc32a69
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
closesodoo/odoo#54444
--task: 2296213
Related: odoo/enterprise#11833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
Also, this commit fixes the usage of the 'invoice_policy' field in test that is introduced by the 'sale' module.
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
If a test is supposed to be run with the Belgium CoA, we expect the company is created by default with the EUR currency.
Before this commit, the currency of the company was replaced by the current company's one: USD (most of the time).
The tests must be only imported in a test context, not in a running
context.
Since 92a7f8c a new test requirement was added but it should
not be necessary to run a module, only to execute the tests.
closesodoo/odoo#53628
Related: odoo/enterprise#11882
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Xavier Dubuc