account.move.line has a journal_id field that is related on move_id.journal_id.
By searching on journal_id we avoid a useless join,
offering more room for database query optimizations.
closesodoo/odoo#81856
X-original-commit: 2741f245f8a47e971309e97128662f1863329e45
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
createTransactionRequests can return responses like this:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': 'XXXXXXXX',
'accountType': 'eCheck',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '33',
'errorText': 'Bill To Address is '
'required.'},
{'errorCode': '33',
'errorText': 'Bill To State/Province is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': 'xxx',
'transId': '0'}}
_make_request() threw out the detailed errors ("Bill To Address is
required" and "Bill to State/Province is required") and only returned:
{
'err_code': 'E00027',
'err_msg': 'The transaction was unsuccessful.'
}
which results in the following vague error on an SO:
The transaction with reference SO1111/1111111 for US$ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful."
This commit extracts the transaction errors and appends them to
'err_msg'. After this commit the above response results in this chatter:
The transaction with reference SO1111/1111111 for $ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful. Bill To Address is required. Bill To State/Province is
required."
Ideally the error handling logic would be rewritten so that
_make_request() doesn't handle specific errors like this. But changing
it is too high risk in a stable release.
opw-2718318
closesodoo/odoo#82443
X-original-commit: c7b292f7b86679b11527a68093ed70b36dc2fd1a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Header of XML files should not be translated.
Before this commit, some users may translate the XML header and get
invalid XML if translating words like "encoding"
Fixesodoo/odoo#82155closesodoo/odoo#82439
X-original-commit: aaac6fc04f4e5aa4c9ad68d9e844f3e786044800
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previously, relational required fields had their auto-generated inverses
defined with `isCausal: true`, which seemed logical: if a record is
deleted, all the records that depend on it must be deleted too.
In practice, it turned out to be a bad idea since there are some cases
where you don't want the dependent records to be deleted. For example,
there is no point in deleting the current record when a required field
is replaced by another one.
Furthermore, this actually led to the introduction of new bugs, as the
one described in task-2730667.
Fixes bug described in task-2730667.
Reverts some of these changes: https://github.com/odoo/odoo/pull/81679closesodoo/odoo#82437
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since the refactoring of the views aeb8e49972f871b0c9b07c507987ee77cf5e8abbd,
the filters and date filters, the groupbys and date groupbys are now
always separated visually even if no separator/group tag has been
set in the search arch. We restablish the previous behavior that only
seperates them when a separator/group is set.
closesodoo/odoo#82418
X-original-commit: e281bd0850e935ce0d97226366114da4f5406c4d
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Step to reproduce:
- Inventory > Configuration > Operations Types > Manufacturing (or any other operation type with code 'mrp_operation')
- Change 'Type of Operation' to 'Receipt' (or any other but 'manufacturing')
- Uncheck box field 'Use Existing Lots/Serial Numbers'
- Change 'Type of Operation' back to 'Manufacturing'
- Set correct value for 'Default Source Location' (type Receipt changed the value to 'Vendor', need to fix it)
- Create a storable product with the route 'Manufacture' selected.
- Create a BoM for this product, with a component tracked by lot (Add quantity to component)
- Create a MO for the product > Confirm > Check Availability
Current Behaviour :
Quantity are reserved, but the lot_ids are not visible
The behaviour is due to the fact that hidden parameters still have effect when they should act as their default value. To ensure it's the case, they are set back to their original value when the user switch between configuration to avoid ending in a wrongful configuration.
Behaviour after PR :
Lot ids are shown no matter the hidden configuration of picking type
opw-2680370
closesodoo/odoo#82377
X-original-commit: 22bbf43eba0927bdf27218da16f8435b33756112
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
This PR make the activity popover test use the mock model and a chatter as
component.
closesodoo/odoo#82143
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds the possibility to open the custom main command palette.
So it is possible to replace some parts of the default command palette
config.
For example, we will customize the placeholder:
```
this.command_service.openMainPalette({
placeholder: "My custom placeholder",
})
```
This commit also modify the api of CommandPaletteConfig, we replace
namespace by searchValue. Now it is possible to open a command palette
with a value in its input.
For example:
```
this.command_service.openPalette({
searchValue: "@test",
})
```
closesodoo/odoo#81814
Signed-off-by: Géry Debongnie <ged@odoo.com>
Purpose
=======
Change weird formatting sometimes showing "In" or "ago" without
displaying any text, give user better awereness of when a room/track
starts or has started.
Specifications
=============
Change widget in website_event_meet to digital: False, display "Starting
now!" if track starts/has started within less than 60sec, display info
box showing when page was last refreshed.
Task-2677865
closesodoo/odoo#79082
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Attachments that are uploaded on a record that isn't saved yet are
created with res_id set to 0. In the case of attachments linked through
a m2m rather than the usual (res_model, res_id), it means they may not
be readable afer the creation of the record, except by their creator.
Re-attaching them to the mailing / template at the end of the create()
call fixes the ownership.
Fixes#81935closesodoo/odoo#82120
X-original-commit: 05fb705f2729ffdf07ab36accda20415a44e1aa6
Signed-off-by: Olivier Dony <odo@odoo.com>
Purpose
=======
Allow users with enough access rights to disable next-day report on
mass mailing lists. The option has been added in the mass mailing
settings and is enabled by default. Mass mailing reports can also be
disabled with a "Turn off mailing reports" button in the report email
itself. Reports are enabled and disabled for all responsible.
Task-2692211
closesodoo/odoo#82430
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a toaster notification would be shown in addition to
the dedicated error div in the inline payment form when an exception is
raised while trying to archive a payment token.
closesodoo/odoo#82420
X-original-commit: ff7368a4d140a5fe7cf995d61847e81c6a7fd65e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Step to reproduce:
- Create a Project with task A
- Create a Sub_Task to task A named sub_task B
- Create a Sub_Task to sub_task b name sub_sub_task C
- Duplicate Project
Current Behaviour:
- sub_sub_task C (copy) has no parent_id
Behaviour after PR:
- sub_sub_task C parent_id is sub_task b (copy)
opw-2727220
closesodoo/odoo#82417
X-original-commit: dbf27b60041e53b12fc79ac2f67197d1a77a1d8c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Issue:
If the sales timesheet module is installed and the task has an Analytic Tag set,
the tag does not appear on the timesheet.
Reproduce Step:
- Install sale_timesheet
- Analytic Accounting Tags and Analytic Accounting active
- create the task
-Insert timesheet and Analytic Accounting tags
- Tag empty in Analytic Items
closesodoo/odoo#80494
task-2667754
closesodoo/odoo#82375
X-original-commit: 3289c23a4b1b3a43dc125acded1e790cfb826c95
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When using a product attribute with a creation mode defined on "never",
the order sent to the kitchen doesn't consider the product attribute
value
To reproduce the issue:
(Use demo data)
1. Create a product P:
- In variants, add the "size" attribute with at least two values
- (Note that the creation mode of this attribute is "never")
- Available in POS
- Category: Miscellaneous
2. In Point of Sale, edit the "Bar" POS and enable:
- Product Configurator
- Order Printer (the Kitchen Printer must be working)
3. Start a POS session
4. Select a table and add:
- 1 x P with a size value
- 1 x P with another(!) size value
5. Send the order to the kitchen
Error: The printed order only contains one line: 2 x P with the first
size value selected
When checking if the current order has some changes, the lines summary
builrder does not distinguish the product variants
OPW-2698626
closesodoo/odoo#82316
X-original-commit: 911a178c99fe56c5f644083a0bb5e992a11f34ed
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
A lot of localization are inheriting reports and changing them.
This should be tested in a generic test like /base.test_reports to avoid
possible tracebacks.
closesodoo/odoo#82312
Related: odoo/enterprise#23299
Signed-off-by: William André (wan) <wan@odoo.com>
Two key are used for the same purpose. Remove one and
use its content directly in the report
clean commit bef1765b197a9e9d510a7d20d0364333402473b0
Part-of: odoo/odoo#82312
The number is set as zeros, but we should still provide
the IdPaese tag.
opw-2703669
closesodoo/odoo#82398
X-original-commit: 3e4361ff621e5458e6a2ad09610274bf33290106
Signed-off-by: William André (wan) <wan@odoo.com>
In saas-15.1 move_lines on `stock.picking` has been rename in
move_ids.
It was miss during #81595 and it's fixed now
closesodoo/odoo#82397
X-original-commit: fd531c7b0baa742cefb7a09c557617806d8a563a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Before this commit, when the a subtask is in the same project than the
parent one and the internal user has manually set the project to see
this task in the main kanban view of tasks of the project. In project
sharing view, the collaborator cannot see the 'View Task' button in the
sub list view of subtasks shown in the form view of the parent one.
This commit fixes it to shown the button when the subtask is in the same
project than the parent one.
Steps to reproduce:
==================
1) Create a Project A
2) Create a Task T in the Project A
3) Add a subtask in T and set the project A in the subtask
4) Share in edit mode the project A to a portal user
5) Log out and log in as the portal user
6) Go to the Project A to see the kanban view of tasks in project
sharing feature.
7) Go to the task T and see the subtasks list view.
Expected Behaviour:
==================
The 'View Task' should be shown for this subtask because the subtask is
in the same project than the parent one.
Actual Behaviour:
================
This button is not shown.
Bug found during the testing of the task-2648955
closesodoo/odoo#82383
X-original-commit: ddafb7fa5aff30e2cb16dcdcb5cdbd44397de126
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When we create a record with a very long continuous title (without spaces) the string comes out of the kanban block.
Reproducible on several applications such as Notes, CRM, etc.
opw-2680915
closesodoo/odoo#82348
X-original-commit: efe1312535b3af20c81cfd6cb10cbf3e7e5f8f90
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The "My department" filter in the "Time Off" overview menu is changed to also include the leaves of employees from child departments (all the way to the bottom of the hierarchy).
task-2699541
closesodoo/odoo#81597
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When we ack a file for having correctly received the response e.g.,
the file is deleted on the server and will not have a file key in the reponse,
at least before the server itself will have a new response to share.
Before, it would traceback, while now, we do nothing. (as we are still waiting)
Also, when we get the notice that the term of 2 weeks is passed, it means
it is successfull.
Also, for the batching we had a traceback, because it was possible to have
a batching mixing step 1 and step 2, which fails doing invoices.l10n_it_edi_transaction
So we added whether there is a tranaction or not in the batch key.
opw-2703669
closesodoo/odoo#82358
X-original-commit: c20e3b95a82fd35c1dcefd159525f59e2c255e9d
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Connect as Admin
- install stock_account
- Go to inventory > Product Variants > choose any product > click on the FORECAST button
- Traceback
Problem:
docs['product_templates'] can be False, so we can't use it to check the user's group: https://github.com/odoo/odoo/blob/15.0/addons/stock/report/report_stock_forecasted.py#L98
Opw-2728473
closesodoo/odoo#82352
X-original-commit: 227a639b34fc5121d135346a158ab17486a53d40
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
use case to reproduce:
receipt a product tracked by lot
produce a lot with a component tracked*
open the traceability report for the lot's component
you have a traceback.
it's due to last_delivery_partner_id field present in the tree view of lots.
it triggers _compute_delivery_ids that call _find_delivery_ids_by_lot in multi.
the call in the recursion(trigger by *) redefine delivery_by_lot and erase the previous result.
so the cache is not correctly update and traceback
closesodoo/odoo#82351
X-original-commit: e6bcc77c58d39adbd782e776eb2f6d5c470eb0e2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current behavior :
When sending an invoice by email there was 2 signature in the mail
Steps to reproduce :
Create an invoice
Send it by email
Check the mail, there are 2 signatures
opw-2703272
closesodoo/odoo#82347
X-original-commit: 00965df4be591b952b339038c324d7e92596e3d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior :
Any users (not only internal users, but portal users too) can be selected
from the `Salesperson` field in the Settings.
Exepected behavior :
Only internal users can be selected.
Steps to reproduce :
- Install eCommerce
- Go to Settings, Website category
- Find Orders Followup category
- Try to pick a salesperson
OPW-2709759
closesodoo/odoo#81368
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The enterprise module website_helpdesk_forum changes the demo data
karma_answer value to 0 for the default Help forum thus breaks the tour.
odoo/enterprise#19870odoo/upgrade#2681closesodoo/odoo#74353
Taskid: 2499623
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The aim of this commit is to allow EDIs to create and save account move
even if a supplier reference is duplicated.
This is achieved by delaying the moment to which the constrains is
triggered.
Before this commit:
A user can only upload a bill once. (xml ubl format for instance)
If he needs to upload it a second time, he will be forced to find a
workaround.
After this commit:
User will be able to upload as many bill as he wants but will receive a
ValidationError when trying to post the invoice if the reference is
duplicated.
The user will be able to post the bill very easily by changing the
reference a bit if he wants to pursue.
closesodoo/odoo#82303
Community-pr: https://github.com/odoo/odoo/pull/81748
Enterprise-pr: https://github.com/odoo/enterprise/pull/23255
Task: 2612299
X-original-commit: 200614876e62192e1a5ce2f30ec7aa8a1de77672
Related: odoo/enterprise#23281
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
- Users > Admin > Acces Rights > Human Resources
- Time Off : empty
- Time Off > a past day > Time Off Request wizard :
- Time Off Type : Sick Time Off
- Confirm
Issue:
- User Error : 'You must have manager rights to modify/validate a time off that already begun'
Cause:
- When creating the request, attachments are writen onto the record.
- Yet the user do not have rights to write in hr_holidays.
Fix:
- sudo in the compute and inverse methods that write the attachments.
opw-2714597
closesodoo/odoo#82311
X-original-commit: 9bc197fcf6c87678c82863706344e449b1cd69c1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Current behavior :
Mail body is missing on mailing demo
Steps to reproduce :
- Install Email Marketing & Sales
- Go to Email Marketing
- Select "Our last promotions, just for you !"
Reason :
mass_mail used to the body_html but since this commit (de56e1919d11cc497341f59ef38fb2d756ede7a3) it now shows the body_arch field (and body_html in debug mode).
OPW-2702534
closesodoo/odoo#82279
X-original-commit: a4a6f786c5f8deb424132ef4edff62e2662d5d58
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
* When a user is already muted when setting their state as deafened
the mute state should remain after the deafen state is removed.
* When a user clicks the microphone (mute/unmute) button while being in
the deaf state, the user should end up undeafen and unmute.
task-2720026
closesodoo/odoo#82197
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, a ValueError would be raised upon receiving a refund
notification for a source transaction whose reference was not found in
the database. As only ValidationError's are caught by the webhook
controller, the acknowledgment string was never returned to Adyen and
the endpoint was automatically disabled.
This commits adds a check on the existence of the source transaction to
allow discarding refund notifications if it is not found.
task-2704522
closesodoo/odoo#82291
X-original-commit: 06d79dc3d01079db27f16dc56212cf68635e8c5d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
As the query results are set in a list of dicts relying on the
position of the dicts inside the list, the SQL query must ensure
the results returned by postgres are ordered properly so that it
will match the order in which the dicts are defined inside the list.
closesodoo/odoo#81978
X-original-commit: bac93bf56ff67a89f9381137b0c67642a302e6bb
Signed-off-by: Laurent Smet <las@odoo.com>
with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report.
odoo/enterprise#21591
Task-2585661
closesodoo/odoo#82224
X-original-commit: 4d074686c1eb716020b950ea86650ecf2bda08aa
Related: odoo/enterprise#23244
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
When you disable the headers through the website editor and try to add
a product to the wishlist, a traceback occurs because there is an animation
that uses the dom element of the wishlist that doesn't exist.
We can avoid the animation in the case where the wish is not defined
reproducible in 14.0 with the wishlist (must be activated in settings)
and in 15.0 with the cart and the wishlist
opw-2722163
closesodoo/odoo#82294
X-original-commit: 2a9768f6a09751af82ccabee3d565f622ea418f3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when the project has no SO set in its model and it
has a task with a SO set. When the user clicks on the Sales Order stat
button shown in project form or the project update. He sees a form view
of `sale.order` to create a new record because the action does not give
the id of the Sales Order related. Indeed, we give the id of the SO set
on the project if we found only one SO related to the project.
This commit fixes the issue by given the id of the SO related to allow
the user to see the SO related to the project.
Steps to reproduce:
==================
1) Create a project A with allow_billable set to `True`.
2) Create a Quotation for a customer C with a SOL containing service
product and confirm it to create a SO.
3) Create a task in the project A and set the customer C to this task
and set the SOL of the SO created in the step 2.
4) Go to the project update of the project A
5) Click on the 'x Sales Orders' stat button.
Expected Behaviour:
==================
The user should see the SO related to the project, that is the one
selected in the related task.
Actual Behaviour:
================
The user sees an empty form view of `sale.order` to create a SO because
no SO is found.
Part of task-2710808
Closes#81940closesodoo/odoo#82284
X-original-commit: de702d921a321a8b783af020538ceaf4ef3af10f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the project has a SO related, the 'Sales Order'
stat button is shown in right side panel in project update even if the
allow_billable=False in this project. If `allow_billable=False` then the
project should be non billable and thus this stat button should not be
visible.
This commit hides the stat button when the project is
non billable.
Steps to reproduce:
==================
1) Install sale_timesheet module
2) Create a billable Project
3) Edit the project to set a SOL (Set a customer and a SOL) and save.
4) Edit the project and set `allow_billable` to `False`.
5) Go to the kanban view of the Project Update.
Expected Behaviour:
==================
The 'x Sales Orders' stat button should not be visible.
Actual Behaviour:
================
The 'x Sales Orders' stat button is visible.
Part of task-2710808
Closes#81940
X-original-commit: bc0226583a48f9eefc79c3e2a8e7069d6181f8ea
Part-of: odoo/odoo#82284
Add a populate script to automatically create lots of
employees/jobs/tags/work locations/departments.
closesodoo/odoo#82259
Taskid: 2728608
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fixes a case where the track could be left enabled when
transitioning from voice activation to push-to-talk (the track would
still properly be disabled on the next release of the push-to-talk key).
part of task-2720026
closesodoo/odoo#82273
X-original-commit: 96804f4eba76ce3c016ae34a9829f88ab8c7e0f3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, the mail_channel/add_member function use multiple _sendone. We
can compile the notifications inside a single sendmany.
Task-2726415
closesodoo/odoo#82198
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this changes, we only use the last value to determine the customer satisfaction of a task. The problem is if the customer was happy during all the process of a task and at the end of the task, he is unhappy. The customer satisfaction for this task will be bad because the last rating made for it is negative.
Moreover, the customer satisfaction shown in `project.project` model computes the percentage of Happy ratings divided by the total of ratings in its tasks. For instance, if we have a project A with 3 tasks T1, T2 and T3 and we have a rating for each task as follow:
- R1 for T1 has 3/5 as rating value.
- R2 for T2 has 5/5 as rating value.
- R3 for T3 has 1/5 as rating value.
So the percentage of Happy Rating will be equal to 33% but globally, we could see the customers were globally okay for this project because the rating average is equal to 3/5. Indeed only one customer was happy but all the others have not given 1/5 as rating score. So the project could globally be acceptable for the customers.
The goal of this changes is to only use the rating average instead of using the last rating value (for the tasks) or the percentage of happy rating for the projects. With the rating average we could have a global idea of the customer satisfaction for a task or an entire project.
task-2671848
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#81027
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This fix removed the duplicates of an empty order when using the floor management. Before, when syncing order without order lines, it was creating an empty order in the backend.
When reloading the table, it was creating a new empty order, ignoring the previous one. That problem lead to empty unpaid draft order.
closesodoo/odoo#57952
Task-id: 2308862
Signed-off-by: Masereel Pierre <pim@odoo.com>
Stéphane Bidoul