All write operations on the `project.task` model are slowed down significantly
by a dict comprehension mapping tasks to their user_ids because of the access
rules checks. By adding a sudo to that dict comprehension, this commit makes it
bypass those checks and speeds it up.
Task-3164004
closesodoo/odoo#115037
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: pos_epson_printer, pos_restaurant, pos_six
This commit continues the work of reducing the reliance of the pos
modules on legacy features from the JS framework, such as core.Class and
mixins, by converting the ProxyDevice class to ES6 (and renaming it
HardwareProxy, to avoid confusion with DeviceProxy from iot). It also
makes it available as a service in the new environment so that we can
hopefully get rid of the legacy environment in the near future.
closesodoo/odoo#114821
Related: odoo/enterprise#37991
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose:
- In the project, My Tasks and All Tasks menu are related to the task model so
having two main menus for the same model which display almost the same
thing would not be great for UI and it'll not look good if we add another menu
in the future or via customer customization.
So in this Commit:
- We have added a menu named Tasks which has 2 sub-menus My Tasks and All Tasks
which would be great to display tasks
task-3180910
closesodoo/odoo#113335
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- the sequence field should not be optional for project.task.type list view
- move the fa-play icon next to the remaining hours widget in kanban view
- add filter and separator for burndown chart search view
- transform the 'milestones' stat button into 'x Milestones /n y Reached
- change the recurrence banner
- add the placeholder for the label_tasks field 'e.g. Tasks'
task-2947481
closesodoo/odoo#99528
Related: odoo/upgrade#3872
Related: odoo/enterprise#31047
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit total time on timesheet for projects and
invoices computed according to user's access to timesheet and
security rules on account.analytic.line are quite complex.
So, in this commit compute those fields with sudo to ease the
perfomance of project and sale apps.
task-2890184
closesodoo/odoo#99372
Related: odoo/enterprise#30950
Related: odoo/upgrade#3843
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR add a populate command for models `mail.channel`, `mail.channel.member`
and `mail.message`.
It will only create channel of type `channel` and `group`.
I used this bash function to quickly delete/create a database and populate it.
```bash
# Quickly drop the current db (it use the git branch name as database name) and
# create a new one that will be populated.
# usage: odoo-populate model_name size
odoo-populate() {
dropdb $(git branch --show-current)
odoo -i mail --stop-after-init
./odoo-bin populate --models $1 --size $2 -d $(git branch --show-current) --addons-path=~/projets/pro/odoo/addons,~/projets/pro/enterprise --c ~/projets/pro/.odoorc
}
```
closesodoo/odoo#115827
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The allow_group_range_value option is used in one arch of a kanban in
CRM. We therefore believe that this is not standard behaviour.
So we decided to move this logic to the custom view that uses it.
Part of Task: 3179751
closesodoo/odoo#117023
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Quotation templates feature simplifies creating Sale Order on backend.
To make the process even faster, Odoo allows set up Default Quotation Template,
which is applied automatically on every new quotation. However, it doesn't make
sense to apply quotation templates for orders created by eCommerce users.
Particularly, it leads to an error if quotation template has recurrence.
Fix by ignoring default quotation template on eCommerce sale orders.
STEPS
1. Create a sale template with a recurrence
2. Set this sale template as the default sale template in settings
3. Go to /shop page and add any product to cart that is not recurring
-> The sales order will be created with the default template's recurrence
4. Try to pay & confirm the order
-> Error when trying to make an order with recurrence and no recurring product
opw-3115232
closesodoo/odoo#116913
X-original-commit: 1d083cad6fe9a5e2356e53ac922c8ff9e75d52f6
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
In order to be able to see all quotes linked to a crm lead,
we now allow cancelled quotes in the domain of leads of the
stat button action. The cancelled ones are not shown
until the 'quotations' filter is removed in the search.
Also, cancelled ones are not accounted for in the counter.
To do that, we create a specific domain method for the action,
and override it in sale_renting_crm to exclude rental orders.
The _get_lead_quotation_domain is not directly modified as one
would also need to exclude cancelled quotes in _compute_sale_data.
Also, we cannot add an expression.OR method in the action
code, because the domain is extended in sale_renting_crm and the
domain order of operation could include cancelled rental orders,
which is not desired.
Task-3237734
closesodoo/odoo#115864
Related: odoo/enterprise#38957
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Bigger and centered emojis in grid
- Better visual clue of focused input from search icon
- No search screen with icon + text
- Consistent sizing of emoji picker in case of failure
- Added basic test for active highlighted category
closesodoo/odoo#117001
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Before this commit, no default date filter was set on the report.
For older databases, it results in a systematic heavy query.
opw-3134913
closesodoo/odoo#116770
X-original-commit: b8b75d5bdd8901d2c8fcd54d63c78c0d36254933
Signed-off-by: nda-odoo <nda@odoo.com>
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>
Vincent Larcin