Fixes an issue with the tax total computation that would happen
if the tax of type group has the same tax_group_id as one of the
children taxes.
This would lead to a tax total computation where the other child
of the tax will be summed into the child sharing the same tax
group.
As it is no longer possible to set a tax group id on a tax of
type group, we do not need to take it into account when computing
the tax total anymore.
To reproduce before the fix:
- Make a bill with the Australian tax au_tax_purchase_10_service_tpar_no_abn.
- Save.
- You will notice that the amount in the tax total widget for the tax
"GST 10%" is wrong as it takes into account the amount of the other
tax.
After the fix, the amount will not be wrongly grouped anymore. And the
tax total will correctly represent what is in the line_ids.
Task id # 3252271
closesodoo/odoo#117093
X-original-commit: aa736d7d0189784e6ff81b7acfcd0ac0e1cbe6b7
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Use case
--------
If the a user has partner_share set to NULL not to 'false'
he will not receive any notification
The orm consider False and NULL value as False for boolean field,
the query that fetch the recipient data should have a consistent
behavior
closesodoo/odoo#117083
X-original-commit: a50fbd1f9404fd05eb576474eb3d10c94d37aa52
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
While presenting a survey, sometimes it is good to know what content
will be next. However, this is not possible currently.
This commit improves the behavior to display a tooltip msg on the right
arrow so that the presenter/speaker knows what is next.
Task-2791000
closesodoo/odoo#97713
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the invoices were marked as sent only when
sending them via email or post.
After, it is mark as sent once the PDF is being generated via the
send&print wizard, as it becomes computed based on the presence of
the PDF.
Rational, we want to consider a generated invoice via the
send&print wizard as being sent as it can be printed/downloaded.
This also makes the invoice available in the portal.
closesodoo/odoo#117085
X-original-commit: 9e656aabe4f6840ee5c200a21832dad958ea6892
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
When creating analytic lines from bills or invoices, the category is not put on them.
opw-3214062
closesodoo/odoo#117056
X-original-commit: 7729b5bf006d0a988ce84e2f953749866fae7b16
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When creating an invoice from e-commerce, the invoice is not sent by mail but the user must be able to see it from the portal.
closesodoo/odoo#117033
X-original-commit: 61d3b9d7186eb82b3227c65c26f629672f99d446
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The computation of `<account.move>.made_sequence_hole` on the list view
takes a non negligible time (about 1/4 on test server), for instance on
* Accounting > Vendors > Bills
* Accounting > Customers > Invoices
* Accounting > Accounting > Journal Entries
The less sequence resets there are (yearly reaset instead of monthly, or
even no reset at all), the worse this gets.
For instance, the plans below are generated on a journal with ~35k
`account.move.line` (and 10M in total) using the same sequence prefix,
you can see that the first plan needed to remove everything after the
index scan whereas the second plan has the right row directly.
Plan Before
===========
```
Nested Loop Left Join (cost=198.96..1160.00 rows=1 width=4) (actual time=3557.525..3557.528 rows=0 loops=1)
Output: this.id
Filter: (other.id IS NULL)
Rows Removed by Filter: 80
-> Merge Join (cost=198.53..271.00 rows=41 width=21) (actual time=0.360..0.873 rows=80 loops=1)
Output: this.id, this.journal_id, this.sequence_prefix, this.sequence_number
Merge Cond: (company.id = this.company_id)
Join Filter: ((company.fiscalyear_lock_date IS NULL) OR (this.date >= company.fiscalyear_lock_date))
-> Index Scan using res_company_pkey on public.res_company company (cost=0.26..81.53 rows=16 width=8) (actual time=0.007..0.013 rows=2 loops=1)
Output: company.id, company.fiscalyear_lock_date
-> Sort (cost=198.27..198.46 rows=76 width=29) (actual time=0.350..0.474 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Sort Key: this.company_id
Sort Method: quicksort Memory: 31kB
-> Index Scan using account_move_pkey on public.account_move this (cost=0.43..195.89 rows=76 width=29) (actual time=0.029..0.329 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Index Cond: (this.id = ANY (...))
Filter: ((this.sequence_number <> 1) AND ((this.name)::text <> '/'::text))
-> Index Scan using account_move_sequence_index on public.account_move other (cost=0.43..21.67 rows=1 width=21) (actual time=0.076..44.451 rows=1 loops=80)
Output: other.journal_id, other.sequence_prefix, other.sequence_number, other.id
Index Cond: ((other.journal_id = this.journal_id) AND ((other.sequence_prefix)::text = (this.sequence_prefix)::text))
Filter: (this.sequence_number = (other.sequence_number + 1))
Rows Removed by Filter: 34298
Planning Time: 2.250 ms
Execution Time: 3557.579 ms
```
Plan After
==========
```
Nested Loop Left Join (cost=198.96..371.96 rows=1 width=4) (actual time=0.607..0.608 rows=0 loops=1)
Output: this.id
Filter: (other.id IS NULL)
Rows Removed by Filter: 80
-> Merge Join (cost=198.53..271.00 rows=41 width=21) (actual time=0.336..0.359 rows=80 loops=1)
Output: this.id, this.journal_id, this.sequence_prefix, this.sequence_number
Merge Cond: (company.id = this.company_id)
Join Filter: ((company.fiscalyear_lock_date IS NULL) OR (this.date >= company.fiscalyear_lock_date))
-> Index Scan using res_company_pkey on public.res_company company (cost=0.26..81.53 rows=16 width=8) (actual time=0.007..0.010 rows=2 loops=1)
Output: company.id, company.fiscalyear_lock_date
-> Sort (cost=198.27..198.46 rows=76 width=29) (actual time=0.325..0.329 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Sort Key: this.company_id
Sort Method: quicksort Memory: 31kB
-> Index Scan using account_move_pkey on public.account_move this (cost=0.43..195.89 rows=76 width=29) (actual time=0.026..0.305 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Index Cond: (this.id = ANY (...))
Filter: ((this.sequence_number <> 1) AND ((this.name)::text <> '/'::text))
-> Index Scan using account_move_sequence_index3 on public.account_move other (cost=0.43..2.45 rows=1 width=21) (actual time=0.003..0.003 rows=1 loops=80)
Output: other.journal_id, other.sequence_prefix, other.sequence_number, other.id
Index Cond: ((other.journal_id = this.journal_id) AND ((other.sequence_prefix)::text = (this.sequence_prefix)::text) AND ((other.sequence_number + 1) = this.sequence_number))
Planning Time: 2.766 ms
Execution Time: 0.648 ms
```
closesodoo/odoo#116973
X-original-commit: 1a1742cd825ef9c44ac185ce076cce5f1f789c01
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
1) `survey_user_input.slide_partner_id`: this is a sparse column (so using
`btree_not_null` means a very small footprint). But it makes a ton of
difference when trying to delete a slide.slide.partner entry.
e.g. on a db with 500k survey inputs, the deletion of 1000
`slide.slide.partner` records goes from 40s to 100ms (400x speedup)
2) `survey_user_input_line.survey_id`: this is the inverse field of the
`survey_user_input.user_input_line_ids` O2M field, so the index is
always useful to retrieve the O2M lines. It will also marginally help
for cascading the deletion of any `survey_user_input` record from
case 1).
closesodoo/odoo#116875
X-original-commit: 2dc929cd530ba4fd80c17f91af2bfad02a819dd6
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Before this commit, the margin in the sale_total group was following the total.
It was preventing putton another field before the margin. This commit allows putting
another field before the margin without depending on the installation order.
closesodoo/odoo#116820
Taskid: 3232957
X-original-commit: 03286dffa8693edce846c064795e8a26d5b61890
Related: odoo/enterprise#38886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
textwrap does the ellision and we don't need to replace newlines characters.
It is done for us already (except that multiple newlines will be replaced by
a single space).
closesodoo/odoo#116778
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid search_count in a loop using a filtered_domain.
Also removed a sudo, as anyway this method is already called in sudo in
most cases.
Part-of: odoo/odoo#116778
before this commit, there is typo in unit of measure
after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure
closesodoo/odoo#116764
X-original-commit: 11b89fcffe748e6119648dbc32594f0c0bdcf064
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Purpose of this commit when a project is billable, it is likely to be for one
specific customer. The goal is to allow users to directly set a partner from
the project creation wizard instead of having to navigate to the configuration
menu to get access to the full project form view.
So this commit add customer in project simplified view.
task-3185880
closesodoo/odoo#112602
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- add a space between 'access to:' and the name of the course in SOL nameget.
- hide the 'remaining hours' value if the nb of 'initially planned hours' is
equal to 0 in task list view.
- hide the 'initially planned hours' and 'hours spent' values if they are equal
to 0 in task list view.
- hide the 'milestone' and 'assignees' fields if they are false task calendar
popover
- hide the 'remaining hours on SO' value if there is no SOL set on the task
list view
- use the progressbar widget for the progress field update list view
task-2949984
closesodoo/odoo#112265
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
First issue (functional)
------------------------
Steps to reproduce:
- create a type of leave
- create an allocation for X days for month A without end date
- create an allocation for Y days for month B without end date
- create a leave of X + Y days for month A
Remark:
Months A and B do not have to be consecutive.
Issue:
If allocations have not end date, it is possible to use allocation
in an other interval.
Second issue (display)
----------------------
On the dashboard we see the total number of allocations
even if we cannot place them for allocations without an end date.
This behavior contradicts that of allocations with an end date.
Solution:
---------
Make an additional check on the start date of an allocation.
This verification is very restrictive.
It stipulates that if the end date of a leave is before
the start date of an allocation, the allocation in question
must not be taken into account in the dynamic calculation
to link the allocations to the leaves.
In addition, this verification will make sure to trigger
the hack of the commit 02695aa095428b4ef5045f9c90d1b508ec9d896c.
Therefore a Validation Error will be raised.
From a display point of view, it will be fixed
on the dashboard and in the modal window to make a leave request.
opw-3230286
closesodoo/odoo#117024
X-original-commit: 745221b478e0a587ac51fd3f0fca8e067b473b12
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
With the addition of the pos_daily_sales_reports module, the get_sale_details
function return was different which was deregulating the expectation of
the SaleDetailsReport.xml file (printing detail reports on ticket).
This is now changed thanks to an override of some part of the file
when installing the module pos_daily_sales_details.
closesodoo/odoo#117006
X-original-commit: 79d309d38bdf0ef68c1c85228b94cdea0da55ccf
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behaviour:
Search filter is not showing correct results for projects that are in
overtime. Some projects that are not in overtime are not shown.
Expected behaviour:
Search filter for projects that are in overtime should work correctly.
Steps to reproduce:
- Install Project, Timesheets
- In one of the projects, create a task in an "In Progress" stage
- Add an employee on it, planned hours to 1h, and log in the
timesheet 50 hours (so the task is clearly in overtime of 49h)
- In that task, add an employee, planned hours to 50h
- In the same project, create a task in a folded stage, log in the
timesheet 1h (the task is +49h remaining hours in the green)
- Fold the stage when done editing the stage.
- In the project default view, we can clearly see that the project
is in the red (-49h).
- Filter based on overtime, the project is not present in the results
Reason for the problem:
There is a divergence of behaviour between the compute and the
search method of the `is_project_overtime` on the project.
The compute takes only the overtime of the tasks that are not in a
folded stage. While the search is query all the tasks of the project,
regardless of stage and summing those to deternine if the project is
in overtime. So if you have 2 tasks, one in a folded stage and the
other not, that have `remaining_hours` that are cancelling each other,
the search result is incorrect for that project
Fix:
Update the SQL query in the search method for `is_project_overtime`,
to reflect the domain conditions from the compute about the stages.
Affected versions:
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3182077
closesodoo/odoo#116992
X-original-commit: 69f1441133e30b8dc0cc331afcec933d694665e0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
Despite the behavior which is to recalculate the hours to keep
the same number of days from the point of view of the company,
when distributing allocations for a department,
an incomprehensible calculation appears.
This behavior appears even if all the working times are the same
(both for the company and for the employees).
Cause:
When we need to calculate the number of days for an allocation given in hours,
we use the number of hours per day of the employee.
However, in the case of an allocation by department, this value is `0.0`.
Therefore, we will use the hard-coded `HOURS_PER_DAY` value which is `8.0`.
This value makes sense if the company's schedule is 40 hours per week (8 hours per day).
It is also useful in the case of an undefined company's schedule.
But if the company schedule is defined and is different from 40 hours per week,
this value no longer represents anything.
Solution:
First use the number of hours from the point of view of the company
before using the hard-coded value.
opw-3205685
closesodoo/odoo#116991
X-original-commit: 6ddf340f0f19e1abd58ce8345bdc25763cb32878
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Current behavior:
If you create a product tracked by serial number and set an owner on the
product. If you make an order from the PoS with this product, the owner
wouldn't be set correctly on the picking created from the PoS.
Steps to reproduce:
- Create product A, tracked by serial number, storable, and available in
the PoS.
- Add some quantity of product A with an owner (e.g. "Owner A").
- Create a PoS order with product A.
- Validate the order.
- Close the PoS session, go to the picking created from the PoS order
there will not be any owner set on the picking.
opw-3206618
closesodoo/odoo#116919
X-original-commit: d6c44280eb8a86925392e87cf1a35bfe8b00177e
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Users without HR Officer rights would see an empty avatar for the
employees, as the m2x_avatar_fields were using `hr.employee` as model.
closesodoo/odoo#116972
X-original-commit: 3205680cf902e1b84900f28cfdda5528cbb37ae5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In case we retrieve the maximum number of documents the IAP server
can send, we retrigger the cron to receive more documents, until
we get them all.
Parameter `recipient_codice_fiscale` wasn't used at all, download is
related to the proxy user which is determined by authentication on the
IAP proxy.
See odoo/iap-apps#583closesodoo/odoo#116927
X-original-commit: 43c9820b1d3020d89b1b7ca016754e29d1fc6b58
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Before this commit, when the "Create" button of a m2x is clicked and
an error is returned by the server, a form view dialog is opened to
create the record. We want to know if the error is caused by a missing
required field but not by any other type of error.
So we open the form view dialog only if the error is of type
ValidationError otherwise we display an error dialog.
closesodoo/odoo#116954
X-original-commit: 49bae69c602d1587fe159719667ff8dd0fb23984
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This is useful when using the owl dev tools to have a better feedback on
which app is which
closesodoo/odoo#116948
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit [1], which updates jQuery to version 3.6.3, when dropping a
dynamic snippet (Events, Blog Posts), it appears broken. This happens
because in jQuery 3.5.0, the `htmlPrefilter` function (which is called
when the dynamic snippet content is rendered) has been modified.
The dynamic snippets are broken because auto-closed tags are contained
in the data that are fetched from the server and without the jQuery
regex to fix them, they are never closed properly, which breaks the
rendering. Indeed, the `etree.tostring(...)` function auto-closes the
tags of elements having no content when no method is specified as a
parameter.
This commit prevents auto-closed tags to appear in the data sent by the
server when rendering the dynamic snippets, by enforcing the fact that
they will be used as HTML.
[1]: https://github.com/odoo/odoo/commit/ae1cd3d5bb99b9835501144522b71f152aaf8e34
task-3199318
closesodoo/odoo#116929
X-original-commit: f6cbec8d0116305041f018870ab63e26c8cbef41
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behavior:
When a fiscal position was applied in the PoS, it was considered as a
discount and was shown in the receipt and on the product screen.
Steps to reproduce:
- Create a product with a price of 10€ with 15% tax included in the
price
- Create a fiscal position that map the 15% tax to 0% tax
- Open a PoS session
- Add the product to the order
- Apply the fiscal position
- The price of the product is now 8.70€ but the order show it as a
discount of 1.30€ (e.g 10€ -> 8.70€).
opw-3154499
closesodoo/odoo#116918
X-original-commit: d054e7dd2474fad49dab63bf4b2aef09f57780c8
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce the issue:
1. Change the language to french
2. Go to Accounting > Payment terms
3. Select one payment term
4. Look at the example section
5. Examples are in English
Error: The examples should have been in French
The sentence was hardcoded and not translatable
OPW-3203268
closesodoo/odoo#116883
X-original-commit: 7b244e71284d9bfb7186caa82f33f39902937b96
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
When the template layout was made more mail-client friendly in 16.0
we used padding on a <td> node with
a color background to make it look like a button with centered text.
This approach makes most of the button unclickable.
The fix is to put the padding inside the link itself so that the whole
'button' is clickable. We already do this for most templates.
task-3168757
closesodoo/odoo#116945
X-original-commit: c40327db4f46040d4a6ed0231afcdefd5be47db5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce:
- Go to Dashboards
- Select a long product name
-> The tag overflows
opw-3053801
closesodoo/odoo#116899
X-original-commit: 94897fa258322d02a91b57df7f896d17b514b093
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, if you made a product to be tracked by unique
serial number and then make a sale order with hundreds of units
of the same product, each unit will make a separate line with qty = 1.
The issue is each serial makes a different `stock.move.line` and
`_get_commodities_from_stock_move_lines` groups by move lines, which
leads to the issue.
To solve the problem we need to group the move lines by product.
opw-3212809
closesodoo/odoo#116882
X-original-commit: 3c4a12bac1302c8e39dc2a1c617e6536c2d07d3d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
Steps:
install calendar app.
enable sms template of calendar.
go to calendar event form view.
try to send SMS.
Issue:
traceback clicking `Send SMS' of Send SMS wizard.
Cause:
trying to write on field even though field does not
exist in model.
Fix:
check field exist in model before write on it.
task-3084701
closesodoo/odoo#114824
X-original-commit: b773006055f0c29e56b2719621e2abd80af6b9e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, for the company_id field
the user groups given was base.main_company,
such a group is not existing in the system
after this commit, the group will be changed
to base.group_multi_company from base.main_company
closesodoo/odoo#116939
X-original-commit: e259a33b0bff33005bc119838c517aec804695ae
Related: odoo/enterprise#38942
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, the "Card" payment method would always be shown on
Stripe's hosted checkout form, even if there is no related payment icon
(VISA, MasterCard, Discover, American Express) set as "supported payment
icon" in Odoo.
After this commit, Stripe is instructed to hide the "Card" payment
method if all related payment icons are unset in Odoo. If at least one
related payment icon is set, the "Card" payment method is hidden. If the
"Supported payment icons" field is left completely empty, all payment
methods are available on Stripe.
closesodoo/odoo#116917
X-original-commit: d7e96a771e92020938658cdd4dc4a41c45f1644e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The operator =? is recognized by expression.py as a valid operator but
was not recognized by the Domain class (see the method "contains") as
such.
closesodoo/odoo#116914
X-original-commit: b6495bd51295c513ab0d5c083560ac3a1236bd4f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- In the global settings:
- Activate Comparison Price (group_product_price_comparison)
- Put Line Subtotals Tax Display to “Tax Included”
- Go to a product (e.g. Customizable Desk)
- Set Compare to Price to a higher price than the sales price
- Set a Customer Tax
- Go to the shop on the website
Issue:
The crossed-out price is not the same in the product list page and in the product detail page.
Cause:
No condition of the application of the tax on base_price.
Similar to: https://github.com/odoo/odoo/pull/113108/commits/8b7595deace98da26ee016ca565776ffd537284c
opw-3199343
closesodoo/odoo#116821
X-original-commit: b58014d87d9e7b9520ec8aff35395ec3d921c36e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Before this commit, in a list view, the style of a decoration on a m2o
widget was ignored. For example, when applying the danger decoration,
we want the m2o field to be in red.
How to reproduce:
Go to a list view with a field having the many2one widget and
a danger-decoration.
Have a line that respects the decoration condition.
Before this commit:
m2o field text uses its base colour (blue)
After this commit:
m2o field text uses the colour red for danger decoration
closes odoo/odoo#116621
Forward-port-of: #115831
X-original-commit: 9e0eac2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project,utm
**Before this commit**
With the following steps, it is possible to use kanban column quick
creation with unexpected fields, i.e. creating projects instead of
stages inside a project:
- Project > New > Groupby 'Project'
- Click on the "see examples" link in the column in creation
- Apply any column examples
- Instead of stages inside the project, new projects are created
**After this commit**
The kanban_examples registry elements should now clearly
state which are the allowed groupby fields.
The 'See examples' link will not be displayed if the groupby field
is not allowed.
**Usage**
See the modified files in project and utm modules in this commit.
Taskid: 3246042
Part-of: odoo/odoo#115909
*: crm
Before this commit, the KanbanColumnQuickCreate receives
the groupByFieldString property as a string.
This commit changes that in order to give the groupByField object.
This change eases the further work in same pull request.
Taskid: 3246042
Part-of: odoo/odoo#115909
When passing the customer data to adyen to execute a payment an error occurred if the address did not follow a pattern that might be
unkown to the customer.
This fix allows for the user to be aware of what the issue is through
the logs and inform the customer if necessary.
opw - 3171407
closesodoo/odoo#116936
X-original-commit: 66716551f1f75d228876b49cda9fd92732756afc
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Activate avatax.
Create a contact [1], and validate it with avatax.
Create a product A, priced 11.70, add avatax code [P0000000]
Create a product B, priced 9.85, add avatax code [FR000000]
Create an invoice, add the two products, set avatax fiscal position
Compute taxes with avalara, taxes will be 0.73
Confirm invoice
Taxes will update to 1.35. This occurs during `_post`:
when invoice date is set, invoice sync will recompute taxes
for all lines.
[1]
Client Avatax-test
133 Route 20
North Oxford MA 01537-1210
United States
opw-3174739
closesodoo/odoo#116872
X-original-commit: 7e399b0eb4daa5151eba59a65bc649d453ca6883
Related: odoo/enterprise#38908
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Before this commit, the notebook tabs were skipped when navigating with
the keyboard tab or shift+tab keyboard shortcuts. This commit simply
modify the tabindex to 0, so they are not ignored.
Users can now move through the tabs with the tab key, and press enter to
activate a specific tab.
Note that there is not tests because that kind of user interaction cannot
be simulated from the js code
closes odoo/odoo#116874
Task: #2622077
X-original-commit: 1a9a4aef728b406b4c3a1c99cb66e3fc4fd4ff52
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce the issue:
1. Install modules "point_of_sale", "sale", and "account_accountant"
2. Create a user with only "Point Of Sale User" and "Sales User: Own
Documents Only" access
3. Open a point of sale session and input a different opening amount
=> This resulted in incorrect information being displayed in the
"Closing Control"
opw-3188250
closesodoo/odoo#116877
X-original-commit: dc494bc8e68ddde361e0f73b4b2593a59fdeccba
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
**To Reproduce**
- Calendar > Month View > Create Many Events the same day
- Click on "+x more" link: will open fc popover
- Click on an event: will open owl popover
- Click somewhere in owl popover
**Before this commit**
Both the popovers will close and nothing happen
**After this commit**
It works.
closesodoo/odoo#116912
Taskid: 3246033
X-original-commit: 7ee230d9ecf3678ef4246b81783fedaf82119a53
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Will be reintroduced properly afterward. Currently, even if the
field is defined using ondelete='set null', the M2M relation
doesn't handle the fact that the target table is a real model
and not a simple relational table.
closesodoo/odoo#116880
X-original-commit: f58d2ad669710a353263e418bbf69f5f49145cac
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Changeset #115803 tried to reduce issues regarding the statusbar
chevrons wrapping in an ugly fashion when the number of buttons increase
in the header.
Unfortunately, this has side-effect in other cases which actually
degrade the experience.
This commit removes most of that changeset, with the exception of
keeping the -flex-wrap on header buttons - it's better to break the list
of buttons over 2 lines than breaking the buttons themselves into 2
lines.
Follow-up of Task-3215622
closesodoo/odoo#116857
X-original-commit: bc5aebfca3c4b2f67e235b9e0bbdba6fd58140dd
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Some nightly builds failed due to the hardcoded id present in the `test_order_refund_with_owner`.
closesodoo/odoo#116856
X-original-commit: 9c924888635045a34b1d8521c253f9dda83946bf
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Invalid taxes could lead to invalid results from the
`_prepare_edi_tax_details` fonction. For instance: a tax without tax
repartition lines will be disregarded, which in turns leads to an
invalid xml being generated.
opw-3175701
closesodoo/odoo#116855
X-original-commit: 22b18a17348be6bd3982cbffd31da383442a6433
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
list view
In some occasions, we want to be able to download all edi documents so
the user can upload them on a governemental platform. From the list view
of all the invoice, it is now possible to selected as many invoice as we
want, and with a newly added action download them into a zip.
task-3122424
closesodoo/odoo#116854
X-original-commit: 5171f607e1fddde06b769ebb78d82548ad4dc84d
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Nicolas (vin)