When revamping the message fetching from the headless browser, since
stacktraces are available (by default) on console.error and
console.warning events I assumed it could / would be useful to show
them in the Python-level log. And they *were* quite useful during the
original fixing stage.
However they turn out not to be very useful day-to-day:
* they add a lot of noise and lead to the error message itself being
lost in a big block of red / logging.error
* when a tour fails (which is the vast majority of the failures) the
JS stacktrace always points to the same location in the tour
manager (the one which goes "this step never succeeded") which is
completely useless
* aside from being bundled, normal JS code (where the stacktrace could
be useful) doesn't generally use console.warn or console.error, it's
going to straight blow up with an exception in which case we always
get a stacktrace
Leave the stacktrace formatting for console.trace as that's pretty
much the only point of using this instead of console.log.
closesodoo/odoo#44343
X-original-commit: 34500853f39c9557852cb83cbc274f59d803922f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This is done by introducing a new threshold setting, allowing choosing a date before which all invoices and payments have to be ignored by the accounting. Once this is done, all the balances can be reimported directly, easing the migration to Odoo Accounting a lot.
account.move objects having to be ignored because of this are cancelled, and receive the new 'invoicing_legacy' payment state. account.payment objects are moved to the new 'invoicing_legacy' state and their related account.move is cancelled and marked as invoicing legacy as well.
closesodoo/odoo#41416
Task: 2092377
Related: odoo/enterprise#7071
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The access right on payment_token is based on the partner_id
linked with the user
If there is token link with the public user,
they are shown for every request were the partner_id is not defined
If you are logged with an internal user with sales access right,
you'll see all the payment_token linked with the acquirer
We should avoid both situation and show only the payment_token
from the legit partner_id
the one of the current user or the one given as parameter
closesodoo/odoo#44346
X-original-commit: 9edad5d9018ae357e955a5e21e9366e56caa8e31
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
Adapt drop zone direction when a snippet is dropped in an oe_structure
within a snippet.
Before that, the first and the last drop zone preview (when dropping a
snippet in an oe_structure inside an other snippet) was vertical if the
oe_structure width was smaller than his parent.
Part of https://github.com/odoo/odoo/pull/40690
task-2118980
When you click on an anchor link, this commit ensures that the scroll
is in the correct place if there are fixed menus on the page.
Part of https://github.com/odoo/odoo/pull/40690
task-1894456
Before this commit, when clicking on a channel mention from a chat
window, it crashed with the following error:
`TypeError: channel.detach is not a function`
This happens due to `MailService.joinChannel()` returning a promise
that is resolved with channel ID, instead of a channel object.
`channel.detach()` becomes `<Number>.detach()`, which is treated
like `undefined()`, hence crash.
closesodoo/odoo#44329
X-original-commit: 710fda06c3b30ff2267fcc1d123f15ce031b6f3a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
See sub commits for more details. Here are a sample of main specifications
linked to this task.
SPECIFICATIONS: TICKET MOVE / SPLIT
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
SPECIFICATIONS: FRONTEND
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
SPECIFICATIONS: improve ticket model and fields propagation
Remove date fields from event.type.ticket
Propagate seats definition from ticket template to tickets
Add a description on tickets to use in frontend
Improve naming of event tickets
LINKS
Task ID 2177281
Community PR #43488
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
Some demo data is updated in order to be able to show directly tickets
feature in event, with some registrations already configured. Some basic
demo for questions is also added on first event demo in order to have a
complex event usable in demo mode.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS 1: remove date fields from event.type.ticket
Coming from old ticket implementation there are several unused fields on
event.type.ticket, notably dates about selling. Indeed tickets defined on
event.type are templates and should not be time bound.
Previously those fields were available on event.type tickets but not propagated
to the event tickets. Now they are not available anymore, simplifying models.
We therefore remove them from event.type.ticket model.
SPECIFICATIONS 2: propagate seats definition from ticket template to tickets
Previously to the global feature this commit is a member of, only ticket name,
product and price were copied from event.type to its events. Description has
been added in a previous commit. In this commit we also propagate maximum
seats availability.
Use case is linked to event.type defining a recurring event in a given
location. As seats availability is known it can be copied on all events
linked to this event type.
SPECIFICATIONS 3: improve naming of event tickets
Before this commit, all tickets of an event were labeled the same way
by default, using simply ``<event_name>``. This is annoying when
having several tickets as they had all the same name.
In this commit we fix that behavior by setting the name
* directly from the ticket template when tickets come from an event.type.
Configuring Standard and VIP tickets on an event type will therefore
give Standard and VIP tickets on event;
* generic 'Registration for <event_name>' when adding manually a new ticket
for an event;
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we add a description on event.type.ticket and event.event.type
models. Its purpose is to have a description to use notably in frontend
(website_event and website_event_sale).
Currently a ticket description is available only in website_event_sale and is
the description_sale field of the ticket product. As we now have tickets
independent from products, we introduce a real description field on ticket
that is either put by hand (event), either coming from the product with
event_sale.
Field is therefore also copied from event type tickets configuration to its
event tickets.
Naming on sale order does not take into account ticket description as we
consider this fields as being used for front-end mainly. SO line descripiton
is now updated as the following
* either we have a description_sale on the product, and SO line description
is 'product.description_sale \n event.display_name';
* either not and SO line description is 'ticket.name \n event.display_name';
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
LINKS
Task ID 2177281
Community PR odoo/odoo#43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we make a quixotic attempt to clean call chain implied by
making registrations online, either in event frontend (website_event) or
with eCommerce inclusion (website_event_sale). Purpose is to get rid of some
preparation and data management methods to handle most of the code directly
at CRUD level whenever it makes sense.
We notably
* move at create and write level support of partner_id update: updating
its name / email / phone / mobile;
* move at create and write level support of sale_order-id update: updating
event, ticket, partner;
Using that and some code cleaning some methods are removed and call chain
is a bit reduced.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we move menu definitions in their own file. It eases views
split and move, as otherwise there are dependencies between files that are
complicated to solve. Better to have menus defined in a main file, and updating
them at will afterwards.
We also improve menus sequences and groups, as some were missing or badly
defined.
Registration tree view is slightly updated to include phone and mobile numbers
as those are used notably for communication. They are hidden by default
like email.
Finally a small tweak of event kanban view is performed, notably to have
a better display with dependencies installed. We ensure all cards have the
same height.
LINKS
Task ID 2177281
Community PR #43488
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Before this commit, when typing something in the search view in
Japanese, and then clicking on a suggestion from the IME dropdown
menu, the search view menu did not update with selection.
Steps to reproduce:
- Enable Japanese IME in hiragana mode;
- Type "test" in search view;
- Soft-select another suggestion item, e.g. "テスト";
- Double-click on suggestion item "test";
=> The search view menu still detects "テスト".
As a result, clicking on any of these search view suggested filters
picks "テスト" instead of "test".
This commit fixes the issue by updating search menu when clicking
in a suggestion in the IME menu.
opw-2061590
closesodoo/odoo#44318
X-original-commit: 0bca4c0883f2b58842da6a8c1a4e26bf2444d5f3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this commit, the url widget automatically prefixes the href
url by http:// if no protocol is specified, so that clicking on
the url will by default redirect to an external website.
To prevent this behavior, one can still specify the new option
'website_path: true' on the url field node in the view arch.
Thanks to this, we can remove a similar logic (only implemented on
res_partner model) which automatically altered the value saved in
database to force its 'http://' prefix.
task-2153184
closesodoo/odoo#42118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The issue is: the user wants to send an invoice to a customer, changes
the email template, and after the onchange, the field "Template" of the
wizard is empty.
Here is what happens. The onchange on the template renders a PDF file
with the corresponding invoice document. The rendering builds some
assets to convert the invoice to a PDF document, and former assets are
deleted. The deletion of former assets (`ir.attachment` records)
invalidates the whole record cache, which implicitly clears all the
fields of the record of the onchange.
The problem is that the asset is systematically invalidated by the
rendering of the report itself. This hack changes the CSS assets to
introduce company-specific colors for the rendering of reports. This
implementation is actually not consistent with the fact that assets are
kept in cache by the server.
This patch does not fix the root cause of the problem, but it reduces
the sides effects of it, and makes the issue above less frequent. It
simply consists in not updating the asset's attachment when its value is
already correct.
OPW 2168623
OPW 2171040
closesodoo/odoo#44295
X-original-commit: b1ddd9c95bc642e42eb0d3d51066902d5283ba04
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit implements a simple heuristic to display longer texts
inside the web_ribbon widget: we adapt the font size according to
the text length, and we tolerate to display it on several lines.
This commit also allows to specify a tooltip in the xml (with
tooltip attribute).
Task 2185023
closesodoo/odoo#44279
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
A good practice is to always prefix the name of a template by
the name of the module it is defined in.
So in the case where a template
```xml
<t t-name="module.template" />
```
was inherited by another
Before this commit, one should have written
```xml
<t t-name="other" t-inherit="module.module.template" />
```
After this commit, it becomes more natural, and one should only write
```xml
<t t-name="other" t-inherit="module.template"/>
```
The delivery slip report on stock picking always read the product
description not the one the picker set on stock moves.
This commit takes the stock move description for the report when displaying
stock moves and stock move lines
Task : 2180347
closesodoo/odoo#44182
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The 'Show Detailled Operation' setting on picking type makes the
entire operation tab readonly if set to 'True'.
This could be confusing as the description and date expected fields are
readonly depending on this setting.
This commit makes sure the stock move fields keep their readonly
attribute (or not) independently of the show detailled setting.
Task : 2180347
Due to the setting `ready_to_produce` = `asap` on Bill of Material. The
Check Availability button could be hidden even if some stock moves are
still in confirmed state.
Task : 2121714
closesodoo/odoo#41631
Related: odoo/enterprise#7253
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: adding new component in a specific workorder via the form view.
This behavior is only available if the Bill of Material is in flexible
consumption. Adding new component was already made possible in
e1f518bb83 but the ability to add new
workorder lines conditionnaly in the workorder form view was missing.
Task: 2121714
Consuming product tracked by lot (or serial number ) to produce product
also tracked must ensure the link between the two lots (consumed and produced)
is always set. This test is not done in community version while there is
one in the enterprise conterpart (mrp_workorder module). This commit
move this test to the mrp module to have it everywhere
Task : 2121714
This commit let the manufacturing user to add new components or update
the quantity to consume of existing ones in a manufacturing order even if
the state confirmed. The BoM should be in flexible consumption.
In case of reserved quantity, updating the quantity on a raw move will
unreserve it entirely. We apply the same logic than the stock.picking one
Task : 2121714
This commit adds the possibility to choose in which operation a new product
will be consumed. New product can be added to the production once the
manufacturing order is in state draft.
Before this commit, the new product was consumed
automatically in the last workorder.
Task: 2121714
The next commits will allow changing the initial demand of
confirmed moves as well as adding move once the production
order is confirmed. In order to not duplicate again the unit
factor computation in multiple write and create, make the
field a stored computed.
Unit_factor is stored and only depends on product_uom_qty because
updating only quantity_done (after a partial production for
instance) should leave unit_factor unchanged for the futur
partial production.
Task: 2121714
Steps to reproduce the problem:
- Have user A with B2B group.
- Have user B with B2C group.
- Add simultaneously on both - via write - another group (or call `_check_one_user_type`).
Expected result:
- No problem
Got result:
- Error "A user cannot have both Tax B2B and Tax B2C..."
That's because the check is performed for more than one user each time, while it has
to be record per record. The implementation of `_has_multiple_groups` actually
checks if the passed recordset is only one record, and if not, it looks directly for all
existing users, so also the case of both users A and B being in the same B2x group, but
having a 3rd user in the other group will fail.
Revisiting the query in `_has_multiple_groups`, there's a hidden error when you use it
for only one ID because a missing space.
closesodoo/odoo#44300
X-original-commit: 83f104b2f2fc1345ad067430466c004697a91db9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate the VIES online check
- Create a partner of type Company and add several contacts
- Set the VAT number, save
A call to VIES is done for each contact.
The field VAT is propagated from the parent company to the children,
triggering the check on all partners. This is not problematic for local
checks since those are fast. However, online checks take time which can
lead to a timeout of the request if there are many contacts.
Since the check is triggered through a constraint (`check_vat`), only
one record at a time is checked. Therefore, it is not possible to build
a local list of the VAT numbers to avoid duplicated verifications inside
a single transaction.
The solution is to store the result in cache. Since the call to the
external API may fail (e.g. timeout), we extract the check to store only
the successful calls.
Closes#43939
opw-2181744
closesodoo/odoo#44298
X-original-commit: 0c7a3e95df41d4e12c2c5913c2f39e46f96fe77c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
opw-2122776
* CompAuxNum should be the code of the account concatenated with the id
of the client
* It should be popuated only if it is a receivable/payable
The problem is the export of the partner ID in the column G
"CompAuxNum". We only export the ID of the linked customer/vendor. When
they import the FEC into their software to make tax declarations and
annual accounts. The system will notice if an account is filled in in
the column G and will override the account in column E with the ID of
the partner. As the ID is not a real account, they cannot use the FEC to
import correctly.
closesodoo/odoo#44297
X-original-commit: 955eec233f2a3129dfddca06ad43a426b3cd4061
Signed-off-by: wan <william-andre@users.noreply.github.com>
* remove misleading documentation about a "test failed" message, in
13.0 any uncaught exception or console.error will cause the current
test to be interpreted as failed
* fix tour manager to console.error its step and not add a second
useless error message
* fix menu tester to try and display the failure cause on failure
* improve qunit's test reporter to print the number of tests failed in
case of test suite failure
Should make test failures in tours a bit clearer.
closesodoo/odoo#44296
X-original-commit: 78121b68d099b16f2d775a7a8a963a2a0f474843
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
- Contacts
- Import a contact that will be a portal user
- Test import
Activation email sent
Cause
Testing an import do the whole process including sending an email
because of force_send (email not rollbacked).
Solution
Check if we are testing the import. If yes, do not force
send the email. So, the email will be rollbacked.
OPW-2168868
closesodoo/odoo#44283
X-original-commit: f372334facd189d0a70268e7876511bf1f800a4a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Steps to reproduce:
- install sales and contact
- install another language
- go to contacts, pick a specific contact and set its language to
the new language installed
- go to sales > settings > activate the "product configurator" option
- create a product with a translated variant (the variant has to have
at least 2 translated attributes with custom values)
- create a quotation with the modified contact and the product
with the variant (use the product configurator wizard) > save
- print that quotation
Previous behavior:
product description is not fully translated
the part describing the variants is in the current user's language
while the product display_name is using the associated partner's
language
Current behavior:
product description is fully translated into the correct language
opw-2168102
closesodoo/odoo#44144
X-original-commit: 4a542cbd3655b7058ff4dd22feaeb18c6d3ec510
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now, we can again creates ingenico token on production environment.
Commit https://github.com/odoo/odoo/commit/f0e059e6#diff-0c487d0R558 replaced aquirer.id by self.acquire_id.id.
It is wrong since env['payment.token'].create() will call the function with self == payment.token().
self.acquirer_id == False --> self.acquirer_id.state != 'enabled' --> request done in test mode each time.
closesodoo/odoo#44126
X-original-commit: 68028b90c97f84b40bb5952f7867896456c13253
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Fixes#44133
Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields.
This commits adds missing methods to set Bank account.
closesodoo/odoo#44252
X-original-commit: f66042c96795701c1a313f40fdd320d28e9803ee
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- if checked in settings, OCR can be used to get infos from the attached receipt image
- set default product to EXP_GEN when created from picture
- use "register_as_main attachment" when expenses are created from receipt images
- Add the upload button to the kanban view to see it immediately in the mobile version
and use it to create expenses from pictures. (with or without OCR installed)
closesodoo/odoo#39559
Related: odoo/enterprise#6493
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
In a list view, select some records (either by selecting them one
by one, or by clicking on the header to select all records), then
click on an action (except for the special case of 'Export') in the
sidebar. Some information about the selection is put into the
context:
- active_ids: the ids of the selected records (only those of the
current page)
- active_domain: the current domain
However, before this commit, there were no way to determine whether
the user checked the header checkbox (i.e. all records), or some of
them individually.
This commit adds the information, with a 'select_all' key in the
context.
Note that this is a quick solution, as we need it right now for an
accounting usecase. A more elaborate solution, which will allow the
user to choose whether he wants to apply the action on the selected
ids or on the whole domain, will be developped soon.
Part of Task 2146469
closesodoo/odoo#44248
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Task 2081612
* Add as an optionnal field "balance" (simple debit -credit)
- usefull for "group by"
- usefull when selecting several lines (in the footer total)
- Hidden by default for journal view
- Diplayed by default for ledger view
* Cumulative balance only for ledger views
closesodoo/odoo#38174
Related: odoo/enterprise#8024
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We get a traceback when we try to unbuild a MO
due to a inexistant field call (scrap_qty) instead
of product_qty -> 8458cc1867.
Fix the issue.
closesodoo/odoo#44249
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create and validate a leave
- Go to Time Off > Everyone
- In the Gantt view, move the leave
Nothing prevents the modification of the leave while is it validated.
opw-2179839
closesodoo/odoo#44214
X-original-commit: 05257fc75211ea4b34b35c94eeb42ee5b55bfd5b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
As this race condition seems not possible to be reproduced in local, all this
is an assumption based on the logs.
After the checkout, the user is redirected to `/shop/confirmation` where there
is RPCs fired every seconds to fetch the payment status
(`/shop/payment/get_status`).
As the test was considered as finished on that page, sometimes the RPC would
still be processed in python while the tour was considered done and killed,
thus also the cookies, session & co.
From that point, the python would crash when accessing the session.
In the logs, the python crash in the RPC call occurs after the test is done.
closesodoo/odoo#44235
X-original-commit: 082c660071283c0475e7ce26954803701cd3d659
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
This commit prevent the use of the pricelist in the pos after deactivating the option in the res config setting.
Before, the xml was not shown anymore but the option use_pricelist was still True and we could still see the pricelist in the frontend of the POS.
We were unable to change the option in the backend.
Now, when we untick the option in the res config setting, we disable all 'use_pricelist' in the pos configs.
closesodoo/odoo#41613
Task-id: 2151669
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Xavier Morel