When having a multiple website filters appear on both website.
event_tag_category determines what the filter should be. The problem is if I assign one event_tag_category
one website it also appears as filter on other website.
task-3254058
closesodoo/odoo#118136
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
[1] introduces an issue when a response is sent to an aliased email.
In that case, it is intended that the message should be created by the owner of the alias by [2]
Which breaks the assumption of made in the first commit, as the message is being passively processed by fetchmail.
This causes the owner of the alias to never be notified on reponses in cases where the message could be an alias update. i.e. on any model where the alias applies.
Because the responses are assumed to have been authored by the owner.
To avoid this issue while keeping the behaviors intact we check that we did not come from fetchmail.
If that is the case we consider the author is the stated author for notification purposes.
[1]: c676ed3ea906e99d27a6116cd77218c5ec95b416
[2]: af80c68ae5
task-3383275
closesodoo/odoo#130798
Forward-port-of: odoo/odoo#126189
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
[1] introduces an issue when a response is sent to an aliased email.
In that case, it is intended that the message should be created
by the owner of the alias by [2]
Which breaks the assumption of made in the first commit, as the message
is being passively processed by fetchmail.
This causes the owner of the alias to never be notified on reponses
in cases where the message could be an alias update.
i.e. on any model where the alias applies.
Because the responses are assumed to have been authored by the owner.
As we do not actually care who creates the message records
and deciding the alias owner 'created the message' does not
actually make sense.
We make sure messages are created by odoobot even
if the message was sent to an alias address.
[1]: c676ed3ea906e99d27a6116cd77218c5ec95b416
[2]: af80c68ae5
task-3383275
X-original-commit: 96fe37d37c94c3d6f4642bd6c28d13fcd87075b7
Part-of: odoo/odoo#130798
Before this change aliases were assigned to the user creating them
The purpose was originally to reduce the number of records created by
odoobot however this leads to unexpected
behavior for the users who just wanted to create an alias without fuss
We make remove the default user such that any automated record
modification/creation will be applied by root instead of some
arbitrary user.
task-3383275
X-original-commit: 3edf18168b92545fc29e078a155494f2781adff6
Part-of: odoo/odoo#130798
To Reproduce
=============
- enable multi step routes
- edit Receipts operation and uncheck the two options under Traceability
- create storable product with Traceability using lot/serial number
- make purchase of this product and receive it in your inventory
- under inventory/reports/Locations click on line of this product
you will be stuck at that page even if you click discard
Problem
=======
There is an inconsistency between the view and backend, as we allow
receiving traceable product without setting `lot_id`, but in view
require `lot_id` if tracking is enabled on product.
Solution
========
following this [comment](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move_line.py#L558-L560), `lot_id` shouldn't be required on view.
opw-3422259
closesodoo/odoo#130793
X-original-commit: 768b1755909fa10c39a51c68675b7aa99c91b462
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Steps to reproduce:
-------------------
- create a time off type;
- create two 5 days allocations for an employee;
- validate them;
- create a leave of 8 days for the same employee;
- be in debug mode;
- go to employee form view;
- in action menu, click on "Time off Analysis by Employee and Time Off Type".
Issue:
------
The number of days remaining ("left") for the employee and leave type is -6 instead of 2.
Cause:
------
The query that generates the report is in two parts
```
Find the number of remaining leaves by subtracting leave taken from allocations
(model: hr_leave_allocation and hr_leave) ==> will generate the "left" column
UNION ALL
Find the number of leaves already taken
(model: hr_leave) ==> will generate the "taken" and "planned" columns
```
In the part that generates the "left" column, we relate leaves to allocations.
As there is no "unique" link between allocations and leaves,
we can only link them via employee and type.
We are therefore obliged to use aggregation methods.
The measure that returns negative numbers is:
```sql
CASE
WHEN request.number_of_days > 0 THEN allocation.number_of_days - request.number_of_days
ELSE allocation.number_of_days
END as number_of_days
```
It should be read as follows:
If there are validated or planned leaves, the number of days remaining
for an allocation is the number of days of this allocation minus
the SUM of the days of leaves (validated or planned) for this allocations
(same employee and type).
For example:
2 allocations of 5 days and a leave of 8 days,
we will have (5 - 8) + (5 - 8) = (-3) + (-3) = -6 days remaining ==> this is wrong
In this example, we want: (5 + 5) - 8 = 2 days remaining
Solution:
---------
As it is not possible to link a leave to a specific allocation,
we have to make difference between sums like this:
days left = [SUM(days of allocations) - SUM(days of leaves)]_(for one employee AND one type)
The frontend will sum these days left.
This difference must therefore be calculated only once.
By default, we use allocation with the smallest id.
The result is:
days left frontend = [day left_(for min id) + 0 * (nbr allocation - 1)]_(for one employee AND one type)
opw-3366530
closesodoo/odoo#130781
X-original-commit: a273148cf931f220cc4252c638ae14890f889c9e
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
During the refactor of the module the override
of base.document.layout was removed by mistake,
This is needed to add the PST number to the template
related commit: fd2c6dce8e5bee5ac526e7f3edeb398a992f84b1
runbot build errors: 23816, 23817, 23800, 23801,
23802, 23803, 23804, 23829
closesodoo/odoo#130790
X-original-commit: 32ab5d9b2591a288606f77779d479384bb3b2599
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
RATIONALE
We plan to move from a single alias-domain configuration to a multi
company enabled support for alias domains and aliases. First step to
prepare this change is to cleanup some tests: prepare multi-company
environment, make tests clearer, lessen future diff when updating
alias and alias domain usage.
This merge is mainly about test move and internal content renaming.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Next planned steps
Prepares Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-3453347 (Mail: Move Alias Domain Support)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#130768
Related: odoo/enterprise#45204
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Have all ir.mail.server tests as well as their configuration-related tests
moved into 'test_ir_mail_server' file. That way all tests are contained in the
same file, easing their update.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
Rename alias domain and aliases used a test data. This allows to make
them easier to read, follow, grep and understand.
Activate multi-company on alias and gateway tests, ensuring it currently
has few impact on tests.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
Move alias-specific tests in their own file. This model deserves its own
test file containing unit tests for both alias model and alias mixin. This
helps improving and debugging the model, instead of having them mixed with
gateway-specific tests.
Activate multi-company in setup, preparing multi-company support for aliases
and alias domains.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
If no partner is found for a given email after calling '_mail_search_on_user'
and '_mail_find_partner_from_emails' the returned result is a void recordset
for the email.
When rebrowsing partners afterwards, browsing p.id for each partner leads
to potentially browsing False, which gives a different recordset from a
void recordset. This further causes a crash in '_write_from_google' as
he considers [False] as not being void.
This commit fixes that by correctly filtering out void partners. This is
globally a followup of odoo/odoo#99330.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
Cause by #105848
opw-3427995
closesodoo/odoo#130732
X-original-commit: af1f23c956f7ccbf11d8d5d512f656901c92ad00
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, when selecting a dynamic attribute on the
configurator, an RPC call is made to the server, and the id of the
variant was returned if it existed. If it didn't exist, the server
didn't return the id, and the previous id, if any, was kept in the
client, causing the dynamic creation to fail believing that the product
was already created.
Now, the server will return `False` as `id` if the variant is not yet
created. This value will override any value previously saved as `id` in
the client, allowing the creation of new variants when needed.
opw-3423821
closesodoo/odoo#130720
X-original-commit: 4540f971db2d65bc3453e9579c39109775cd5794
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Make any list binary field with filename attribute
Current behaviour:
- The binary file does not use the filename field
Expected behaviour:
- The binary file should use the filename field
Explanation:
After the updates of list-specific binary field [1], the list
binary cannot get the attributes field name of the record anymore.
[1] odoo/odoo#129631closesodoo/odoo#130719
X-original-commit: ddfa65782a8ff59c07adcb8c56797c57a06789a0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If we use a long enough sequence of field in a custom search filter, the
sequence of fields will overlap the operator or value
Steps to reproduce:
1. Open any view with a search
2. Add a custom filter
3. Use enough related fields in the filter so that it creates a long
sequence of fields, it will overlap the operator at one point
Solution:
Limit the width of the `o_model_field_selector_value` class and break
its content
opw-3450099
closesodoo/odoo#130675
X-original-commit: 472923933e145b39f995051ebe8b45a75669a707
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit's purpose is to allow the user to remove the planned date
end, or the planned date start of a project from the list view, or the form
view of the project. If the user removes either the planned date end, or
the planned date start, both dates will be removed. If the user tries to
add only a date end or a date start while keeping the other date empty
on a project with no planned date, these changes will be discarded.
The goal of this fix is for the projects to always have either both dates
set, or both dates set to False.
closesodoo/odoo#130651
X-original-commit: 250a0d233c8c2e074b967d59d53b1d4aac5feba2
Related: odoo/enterprise#45131
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the user defines a planned date for a project
in the form view, he has to click on `Add end date` button to be able
to select the start and end dates directly in the date picker.
This commit allows to directly select the both dates in the date picker
instead of having the planned date end optional in the form and list
views of project.
X-original-commit: e4f11e7a694c26e23ecf1437f3a98b2d3dd3bd7d
Part-of: odoo/odoo#130651
before this commit, on writing user_id to hr.employee
on multiple record in raisng single ton error.
after this commit, no error wont be raised on the
same.
closesodoo/odoo#130650
X-original-commit: ebc686b8abc84538f224ff4db205ce1231b747c3
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit restores the sheet layout in mass_mailing for consistency
reasons.
The chatter was extracted from the tab it was in and moved back on
the right side.
This commit also fixes an alignment problem when an alert is displayed
and the alert was vertically bigger that the buttons of the status bar
task-3355071
closesodoo/odoo#130616
Forward-port-of: https://github.com/odoo/odoo/pull/126646
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
* Impose the use of the dedicated tour utils to factorize and harmonize
the way tours behave on the ecommerce.
* Introduce new utils when it seems adequate and useful.
This will reduce incoherences and non determinism in e-commerce tours,
and ease future tasks refactoring the e-commerce design and process
(since we'll be able to restrict most changes to the utils instead of adapting
all the tours one by one).
closesodoo/odoo#130378
Related: odoo/enterprise#44938
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Implemented domain exclusion to remove Off Balance Accounts from Account
Mapping in Belgian CoA. This decision was motivated by the rarity of use
of these accounts by our target audience, and their potentially
confusing placement at the top of the list due to their prefix '0'. Now,
the Account on Product and Account to use instead fields will not
display these seldom-used accounts, improving usability and efficiency.
closesodoo/odoo#129576
Task-id: 3431420
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Unless necessary, super should be called first, delegeting ensure_one()
and base logic to the base method.
closesodoo/odoo#129572
Related: odoo/upgrade#4987
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There is no need to have two bridges linking delivery & loyalty.
The two modules held the two parts of the same logic, making no
sense to keep the two modules separate.
Task-3420579
Part-of: odoo/odoo#129572
before this commit, in the sale.report tree
view, the product field was not added.
* sales -> reporting -> switch to pivot
* click on any row to open the tree
after this commit, the product field will
be added in the sale.report tree view.
closesodoo/odoo#129303
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
before this commit, if there is multiple sale order for a
customer, and if we try to create new invoices for this
orders from the tree view, it creates one invoices for
all the orders.
there will be cases, where we have to create separate
invoices for each orders.
after this commit, a boolean will be introduced in the
wizard, by which user can decide one invoice or multiple
invoice by grouping sale order.
closesodoo/odoo#128351
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
create a recursion
Problem
---------
When you have an analytics plans which is the parent of another one, you
should not be able to choose the child plan as parent of this one.
A user has the possibility to do it; when he saves, we he gets the
error: Recursion Detected.
Objective
---------
Don't show the child plans of an analytics plan to avoid the user to
choose something that raises the error.
Solution
---------
Update the domain of the field `parent_id` to exclude the analytic plans
that are the children of the current plan.
task-3414188
closesodoo/odoo#128302
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Commit [1] added a margin-bottom on buttons within snippets to make some
breathing space when several buttons follow each other and appear on
multiple lines on mobile.
However, buttons added by the customer do not have a margin, which
causes misalignment when they add it next to a prebuilt button.
This commit checks that whenever a user adds a new button, if any of its
direct siblings is a button, the newly added button and its button
siblings get an appropriate margin-bottom.
It also reverts commit [1] and removes the `mb-2` class on the button in
`s_text_cover.xml` from commit [2], as it is not needed anymore with
this new behavior.
task-3369604
[1]: https://github.com/odoo/odoo/commit/075e915
[2]: https://github.com/odoo/odoo/commit/5ac340bclosesodoo/odoo#125824
Related: odoo/design-themes#680
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Summary
-------
Currently, the credit limit feature does not correctly take currencies
into account.
Steps to reproduce
------------------
* install `sale_managment`
* enable 'Sales Credit Limit' in the settings
* on a partner's form view, in the accounting tab, enable
`Partner Limit` and set a limit of 50
* have a currency `C` that's weaker than your company currency (we'll
call it `Q`). Let's say that here, `1 Q = 10 C`.
* have a price list in currency `C`
* create a quotation using the partner and price list mentioned above
* add a product with a price of 5, and no tax.
You should be met with a warning indicating that the customer has
reached his credit limit.
opw-3441361
closesodoo/odoo#130652
X-original-commit: f57653a6dcea04f0bca4e5ca73df3e1075e0fe98
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit removes the legacy implementations of Domain, Context
and the pyjs library. All of them exist in the new codebase, and
the few pieces of code that were still using the legacy ones have
been adapted.
Part of task~3439226
closesodoo/odoo#130647
Related: odoo/enterprise#45129
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Prior to this, when searching for a currency in an invoice or journal entry,
"create" and "create and edit" options would show up to propose the creation
of the currency to the user although the currency already exists but is
inactive by default. This could lead to currency duplicates.
This implementation makes it now impossible to create a currency when
searching in a currency field and forces the user to go through the
settings to activate the currency he wants. In addition, we show the
inactive currencies as well in all journal entries that aren't
a miscellaneous operation.
task-3383375
closesodoo/odoo#127707
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Purpose
=======
Fix the traceback which was appearing when toggling
as done the content in the course template.
Specification
=============
The traceback happened because when all the content in the
section has been completed, we want to collapse the next section
automatically. However in this view the sections aren't
collapsable which resulted in calling methods on null HTML elements.
Fixing this by checking if HTML elements exists before trying to
collapse the next section.
Task-3449558
closesodoo/odoo#130633
X-original-commit: 51f82b306ed12dc2c8e32d2a0bd3052f8eed5d2a
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
When finishing (and succeeding) a certification in the e-learning module, you
can 'share' the content of the course by email.
But the "Send Email" button is unresponsive.
This is caused by having nested `<form>` tags: the one of the share modal is
inside the main survey form element.
To resolve this issue, we turn the `<form>` tag into a `<div>` tag in the
sharing template, as it does not need to be a form since it's never submitted.
Indeed, the sharing request is sent through attaching an event handler on the
"Send Email" button which still works fine after our tag replacement.
Note that this fix requires updating the module, but there is no (easy) way to
fix it otherwise, and we consider it acceptable as the impact is pretty low.
In addition to that, we also need to add a survey form JS override to correctly
attach the "ShareMail" widget when the screen is loaded to the "finished" page.
Indeed, as the survey form loads and replaces its content in AJAX rather than
fully reloading the page, we need to watch for the screen refresh and then
manually attach the widget so that the button handler is functional.
During FW to 16.4, we also fixed a small oversight of:
odoo/odoo@e0257347a7
Where we did not correctly add the "email_sharing" parameter when sharing the
certification content in the success screen.
Task-3360175
closesodoo/odoo#130613
X-original-commit: 337762b864d7b06abd7d1622083c5f00d7c7e7f7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The function `get_adyen_endpoints` was renamed to `_get_adyen_endpoints`
It was a typo in the method name, so it was not called and a traceback
was raised.
closesodoo/odoo#130591
X-original-commit: 0c3e1abdeb66805b79e07218c5d5dde89baeb25d
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>
before this commit crm.iap.lead.seniority model is defined
twice inside the crm_iap_mine module.
after this commit, the duplicated model defintion will
be removed from the module
closesodoo/odoo#130620
X-original-commit: 3712256a298a79786f7bbff9a608dcdcc224ce44
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
**Sum of timesheets time different than what the timer displays**
Steps to reproduce:
1. Start a workorder timesheet, then stop it
2. Repeat the process multiple times.
Current behavior:
The error is based on a microsecond precision so you could need
to try multiple times before reaching the problem.
- The time displayed on the timer widget does not display the same as
the sum in the timesheet list.
- The difference between the start date and end date of a timesheet
is not always equal to its duration.
Expected behavior:
- The sum of duration should be the same as the one displayed on the
timer widget.
- The difference between the start and end date of a timesheet
should be equal to it's duration.
The computation of the duration of a timesheet will take microseconds
into account. It's not useful in the timsheets to save microseconds
as the precision is too high and as the user cannot change it manually
anyway.
Removing this precision (i.e. setting microseconds to 0) solve this
problem as it does not trigger rounding errors in a single timesheet
and thus in the total computation of duration of a workorder.
Also, there was a precision rounding error on the timer widget.
Time is saved as minutes in db, and displayed as seconds.
So 2s is 1/30 of min => 0,0333... min.
As multiplying this by 60 will return 1,99999 and as the timer was flooring the result,
there was some difference between the time recorded and the value displayed in the
widget.
enterprise : https://github.com/odoo/enterprise/pull/41727
opw-3241156
closesodoo/odoo#130618
X-original-commit: 0172395fa60c94150609bbbfe174d5eee44525fe
Related: odoo/enterprise#45109
Signed-off-by: Tiffany Chang <tic@odoo.com>
*: sale_product_configurator
Enterprise PR: odoo/enterprise#42551
Steps to reproduce:
1. Install website_sale
2. Create product P
- Go to Attributes & Variants tab
- Add a line
- Create and edit attribute "PILL"
- Display Type = Pills
- Add some attribute values
- Save & Close
- Add the attribute values in the list view
- Save the product
3. Go to website product page
Issue:
The pills have a visible radio button inside, requiring users to click
on the radio button to change the variant. In V15, there was no radio
button, and users could click anywhere on the variant container to
change the variant.
The change in behaviour happened because the jquery code for handling
button clicks has changed. In V15 jquery, clicking a button would
trigger a change event, which would then be captured by the owl event
selector `change [data-attribute_exclusions]`, and the
`onChangeVariant` method was called.
In version 16, jQuery no longer triggers a change event when clicking
a button.
Solution:
Hide the radio input visually, then convert the variant text to a
label. When clicking on the label, the corresponding radio input
is checked.
This means that the whole button is not clickable anymore, only the
text.
opw-3185147
closesodoo/odoo#130615
X-original-commit: dc7af6a4c555740b2c2b13efe57cd971e14dc67f
Related: odoo/enterprise#45103
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When downloading images from Google, we check the headers of the request
to see if "image/" is defined in `Content-Type`. On some websites,
`Content-Type` is not defined, leading to a traceback because we try to
access the key in the dictionary.
opw-3349774
closesodoo/odoo#130612
X-original-commit: f6ecbbf7f72c61623a1f92571536289ffd6231b3
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
- Install product_expiry
- Create Product P:
- Product type: Storable
- Inventory tab > Tracking: By Lots
- Check Expiration Date
- Expiration Date: 100 days after receipt
- Best Before Date, Removal Date, Alert Date: 10 days before
expiration date
- Save
- Products > Lots/Serial Numbers > New
- Product: P
- open Dates tab
There are two different usecases and issues starting from this point.
Usecase 1:
- Dates tab, delete all dates, save
- set the Expiration Date, all other dates are set
- without saving, update the Expiration Date again
Issue 1: The other dates don't update according to the new Expiration Date. This happens because neither if conditions in `_compute_dates` match the case where the product has an expiration date set, but it has not been saved to the lot.
Solution 1: Add an additional condition in the `_compute_dates` method where `lot.expiration_date` is set, but `lot._origin.expiration_date` is not set. This will ensure the other dates are updated correctly when setting the Expiration Date without saving.
Usecase 2:
- Dates tab, set an Expiration Date, save
- Without saving the record, update the Expiration Date several times, with dates in the future
Issue 2: The other dates (Best Before Date, Removal Date, Alert Date) will drift off further in the future, while they should always be 10 days apart from the expiration date. This happens because the new dates are being set relative to the actual value of the date, which changes with each successive update.
Solution 2: set the new dates relative to the value of the `lot._origin` dates, which remain constant between successive (saveless) updates. This will ensure that the other dates maintain a 10-day difference from the Expiration Date consistently.
opw-3374135
closesodoo/odoo#130599
X-original-commit: a275cbcd2d8a87bbd8cadf85c094625ebd8358c4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Markup("") on a HTML field should be counted as an empty field.
Check now the length of the value and assign false for HTML field
if we have an empty string inside markup.
This was leading to an issue where empty alert message were displayed
based on computed HTML field.
closesodoo/odoo#130479
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, if a website does not have a domain, nothing tells
the user that this is a misconfiguration that can lead to broken
behaviours. For example, here are the steps to reproduce:
- Have two website (X and Y)
- Website Y does not have a domain
- Tab 1 has Website X selected
- User opens a new tab
- Tab 2 has Website X selected as well
- User switches tab 2 to Website Y
- No redirection happens
- User switches back to tab 1
- User opens the HTML editor for Website X
- Website X content is displayed
- User saves
- Content is saved on Website Y
This is pretty hard to fix as a lot of the python flow for Website uses
`get_current_website` which will uses the session's "force_website_id"
in priority.
In any case, we consider having multiple websites sharing the same
domain (or having no domains at all) a misconfiguration. Therefore, we
should warn the user of so.
This commit adds a tooltip on the website switcher for websites that do
not have a domain set. It also adds a notification recommending users
close other tabs if they switch website.
opw-3374214
closesodoo/odoo#130448
X-original-commit: bc0c33e3d0026a14af40ed683fe27092a97e71a7
Related: odoo/design-themes#684
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this PR, the user during livechat embed tests was the admin partner while
it should be the public partner. This commit fixes the issue.
part of task-3332628
closesodoo/odoo#130429
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Prior to this, tax groups in Kenya where labeled "TVA".
The labels are changed for a version containing "VAT" instead.
task-3391884
closesodoo/odoo#127109
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Nothing will happen if you click on a product without image, sale comment
and attributes in selfOder if no table was selected before.
To reproduce the issue:
1. Create a product without image, sale comment and attributes (Fill in product name, price, availible in pos)
2. Open a new selfOrder page (without a table selected)
3. Click on the product
Issue: nothing happens, the product cannot be ordered. If no product meets
at least one of the three conditions (image, sale comment or attributes),
it will not be possible to select the table, and thus self-ordering will
be impossible. In fact the table selection only happens during the first
order.
closesodoo/odoo#130614
X-original-commit: 186d60e57da5a5b0182131a936838821a01a7a5f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit change /report/barcode/?type= to /report/barcode/?barcode_type
See ee324e8#diff-8f0bbb50491623995fba965c3d64585c6cbfdbbe519ec95473e472826d253826R1977-R1979
similar fix done previously in `l10n_sa`: https://github.com/odoo/odoo/pull/127222
sentry-3983735307
closesodoo/odoo#130604
X-original-commit: 93b6d3f0bad435a413b1b5b44445ddc4a6cd7852
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
To reproduce:
- Create a Distribution model, with an analytic distribution
and an effect on Partner A
- Create a Sale Order, for Partner A
- Confirm it
- Add a line on this Sale Order
=> The new line does not get the distribution of the model
It couldn't be done before 16.0 because a compute would trigger when posting the sale order, because date_order was used for the default rules, and so would trigger it at wrong times.
Distribution Models don't use this date anymore, so the compute won't happen at wrong times.
task-3355886
closesodoo/odoo#130597
X-original-commit: 22fd34b0d8b944a7afd031b894d750a8291d0aba
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Set "Cash Discount Tax Reduction" to "Always"
Crete the following taxes:
- fixed136:
- Tax Computation: Fixed
- Amount: 0.1360
- Included in price: False
- Affect Base of Subsequent Taxes: True
- fixed176:
- Tax Computation: Fixed
- Amount: 0.1760
- Included in price: False
- Affect Base of Subsequent Taxes: True
- 6%:
- Tax Computation: Percentage of Price
- Amount: 6
- Included in price: False
- Base Affected by Previous Taxes: True
- 12%:
- Tax Computation: Percentage of Price
- Amount: 12
- Included in price: False
- Base Affected by Previous Taxes: True
Create the following products:
- A:
- Sales price: 116.00
- Customer taxes: 6%
- B:
- Sales price: 0.91
- Customer taxes: 6%
- C:
- Sales price: 194.21
- Customer taxes: fixed136, 12%
- D:
- Sales price: 31.46
- Customer taxes: fixed176, 12%
Create a Payment Term "1/7 Net 30" with 1% discount if paid within 7
days
Create an invoice:
- Add payment term "1/7 Net 30"
- Create the lines
- product A, quantity 6
- product B, quantity 350
- product C, quantity 1
- product D, quantity 5
Save
Issue: An error will block the action
"""
The move (Draft Invoice (* 44)) is not balanced.
The total of debits equals $ 1,483.87 and the total of credits equals
$ 1,483.86.
You might want to specify a default account on journal "Customer
Invoices" to automatically balance each move.
"""
This occurs because we compute the balance amounts for epd without
rounding. Then in `needed` we sum up the amounts, ending up with 3 epd lines,
having respectively the following balance:
- 10.145 -> 10.15 after rounding
- -13.6601 -> 13.66 after rounding
- 3.5151 -> 3.52 after rounding
So, because of the rounding, we will have 1 extra cent in debit amount
and the invoice will result unbalanced
Fixing by rounding the partial epd amounts
opw-3327069
closesodoo/odoo#130596
X-original-commit: c9fc35ad5bb437c6e20ea4244178e4f15b7eeac3
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
dane@odoo.com