Side effect due to a combination of odoo/odoo#124182 making field_id not
required to keep trackings when removing fields, and odoo/odoo@9c9552fd20
where field is used to find model when computing groups instead of message
in case the tracking is logged on a model different from the field model
e.g. accounting.
Steps to reproduce:
1. Install project_enterprise in saas-16.4
2. Create a task and update some values for Date deadline
3. Upgrade to 17.0
4. Try to open the task in the upgraded DB.
We get an error:
```
ValueError('All tracking value should belong to the same model.')
```
The reason is that `date_deadline` field is removed during the upgrade
and thus `fields_models` is empty in
https://github.com/odoo/odoo/blob/0649134444fa6b26de1c8c25d7c4a3f70c6d64e0/addons/mail/models/mail_tracking_value.py#L120-L121closesodoo/odoo#156571
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In odoo/odoo@9c9552fd20 a support of tracking value belonging to another model
than the message has been added. In such cases the formatting method written
at odoo/odoo#124182 fails as it expects a single model for all tracking values
it receives. When field is removed 'model' is False, and we fallback on
mail_message model.
Part-of: odoo/odoo#156571
When there is no channel members to be updated the seen status, we
should not send a notification to the channel members, otherwise it
will lead into creating a channel member with id undefined.
test case added to check that the notification is not sent when there
is no channel members to be updated.
closesodoo/odoo#156534
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit changes the computation of product having a negative forecasted
quantity to create manual orderpoints. The issue was that each replenish
location needed multiple `_read_group` on `stock.quant` and `stock.move`
on all storable product.
This commit makes only 3 `_read_group`s for all products x locations and
post process the group and quantity sum by location in Python.
This method gives some performance gain in time as well as in memory
consumption
closesodoo/odoo#156507
Task: 3653272
X-original-commit: 1a061791e68a524480b4f230031af25411603606
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Behavior before the changes:
- When a note was modified, it cancelled the old orderline and recreated
it with the new note.
- Products were not sorted by category in the order preparation display.
- Clicking on the header of an order sent it directly to the next stage,
regardless of whether lines were crossed out or not.
- There were brackets around the order number.
Behavior after changes:
- When a note is modified, it is modified directly on the existing
orderline.
- Products are now sorted by category in the order.
- Clicking on an order header sends only the crossed-out lines to the
next stage. If no line is crossed out, the entire order is sent.
- There are no longer any brackets around the order name.
taskId: 3764317
enterprise PR: https://github.com/odoo/enterprise/pull/57385closesodoo/odoo#155246
Related: odoo/enterprise#57385
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Correct the terms in this module and translate them in Italian.
closesodoo/odoo#156502
X-original-commit: 8f4ded8ebb85e996c2fc556efd0ad080095ff82a
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Function `_pre_reload_data` checks for the existance of accounts with the same
code to avoid creating a duplicate. It does so however comparing with the code
before normalizing it with the length from the template, failing to find
possible duplicates with a normalized code.
closesodoo/odoo#156498
X-original-commit: d60a6d25ad31d85fd3737b0a96ef9958fbed9c70
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- create a relational filter, let's say on `res.company`
- add a default value
- reference the filter in a cell with `=ODOO.FILTER.VALUE("my filter")`
=> every `ODOO.FILTER.VALUE` triggers an evaluation
With this commit, the re-evaluation after the data is fetched uses the
data source mechanism which only re-evaluates when all the data promises
are resolved, instead of evaluating after every resolved promise.
With this commit, the number of evaluations required when loading the
Timesheet report on our prod goes from 5 evaluations to only 3 (each evaluation
is 2-3s) because `ODOO.FILTER.VALUE("Company")` is present two times.
One issue this commit doesn't fix: there one RPC per `ODOO.FILTER.VALUE`
(can be fixed in master very easily because we refactored data fetching)
closesodoo/odoo#156495
Task: 3787125
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
For repaired products with no stock, a new picking is wrongly created,
leading to a gap in the repair sequence.
This because the move is created in 'draft'
and the function does not take it into account.
closesodoo/odoo#156476
X-original-commit: b2f26a522d75d6f1e73076323384163595b29874
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Jean-Francois Aubert (ajf) <ajf@odoo.com>
Once a user posts a review, they are able to edit this single review
and not create any new ones. However if the user had multiple tabs open
of the same course, then they can still access the "Add a review"
functionality.
This fix enforces the single review per user per course policy.
Task-3721958
closesodoo/odoo#156411
X-original-commit: 61a95ad41e0b0c72554a491c555ddd33d8588566
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>
Description:
Since https://github.com/odoo/odoo/pull/76734, the new field
`alias_full_name` is used in addition to `alias_name` to search on
`mail.alias` and route emails in `message_route`. It's also used as
a search criteria in `_search_alias_email` on `mail.alias.mixin.
optional`. The issue is that the table `mail.alias` can grow quite
large, and only the old field `alias_name` has an index on it, which
may not be selective enough, forcing Seq.Scans on the table with
possibly millions of records. The impact is noticeable on
`message_route` which is a hot path for processing incoming emails.
Adding an index on `alias_full_name` allows PostgreSQL to do an
bitmap OR scan on the two indexes, considerably speeding up search
criteria that are a disjunction between `alias_name` and
`alias_full_name`.
Benchmark:
For domain
```python
[
'&',
('alias_model_id', '!=', reply_model_id),
'|',
('alias_full_name', 'in', email_to_list),
'&', ('alias_name', 'in', email_to_localparts), ('alias_incoming_local', '=', True),
]
```
with test arguments, on a `mail.alias` table containing over 2M records.
| | Before | After |
|-----------|--------|-------|
| Timing | 696ms | 1ms |
| Buffer IO | 790MB | 48KB |
Specially impactful as those gains needs to be multiplied by the
frequency of the searches.
Reference:
task-3724844
closesodoo/odoo#156237
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
In some conditions, a x2many field can be considered
as modified by the webclient when in fact there is
no change in 'meaningful' stored fields.
In this case, on save, an empty list of magic commands
will be sent to the server, potentially triggering
unexpected recomputations.
Steps to reproduce:
* install sale_stock & sale_management
* create a new storable product
* create a new SO
* create a new line with this product
* Confirm the SO
* Set or Update the SO delivery date (Other info tab)
* Save
-> In the chatter, you will notice an useless tracking
value being printed for the SO Total, with identical values
before and after update.
Cause
Since the server received an empty list of commands for
the `order_line` field, this triggered a recomputation
of the total amounts of the SO, even though there were no
effective changes in the lines.
Solution
Do not send empty command lists for x2m fields.
This will avoid unexpected recomputation and also improve
performance since the fields were recomputed for 'nothing'
closesodoo/odoo#155549
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Current behavior:
When entering a difference at the closing of the session for a bank
payment method, the daily sales report was not taking into account the
difference for the bank payment method.
Steps to reproduce:
- Start PoS and make a sales with bank and a sales with cash
- Close the session with a difference for both payment methods
- Go to the daily sales report and check the difference for the bank
payment method. The one for the cash is there but not the one for the
bank.
Note:
This bring back the original behavior of the report that was removed
here (https://github.com/odoo/odoo/pull/146341) and makes it coexist
with the current one so that all cases are covered.
opw-3737223
closesodoo/odoo#156376
X-original-commit: d9190e34543c4a1151656859acb41556bcb3a364
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Current Behavior:
Traceback when printing the BOM overview.
Expected behavior:
Generates a PDF of the BOM overview even if the information displayed
is entirely relevant.
Steps to reproduce:
Inventory > Configuration > Products > Attributes
Create an attribute with Variants Creation Mode set to "Dynamically".
Create a new product with this single attribute and multiple values.
Create a BOM for this product with BOM Type set to "Subcontracting".
Print the BOM overview.
Cause of the issue:
Creating such a product generates a 'product.template' that is not
associated to any variant and hence does not correspond to any
'product.product'. As a result the function_get_bom_data made can not
apply the method _select_seller properly in that case.
Notes:
- There is no error if a variant was manually created for that product.
- If the Variants Creation Mode set to "Dynamically" a variant is still
automatically created to be associated to the product tempalte so
that the erro does not rise.
Fix:
As the _select_seller method is only defined for product.product
and not for product.template, we can not not apply it here.
Furhtermore, since the additional informations provided by the
override of the method get_bom_data in the the BOM overview will
not be relevant without the existence of a variant, we skip this part of
the code when the argument of _select_seller is not valid.
opw-3698050
closesodoo/odoo#156346
X-original-commit: b983026f004d4958d2a47a0dac9b1b54e24ab04c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Purpose
=======
Take the last expired contract end date if there is not open contract
for the related employee.
closesodoo/odoo#156326
Taskid: 3610709
X-original-commit: c6ddecc09361cde4580242dc4f87594e78e51a57
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create an attachment with an URL to a static file that does not exists,
e.g. '/web/static/idontexist.png'. Inside your browser try to access
that file, open <localhost:8069/web/static/idontexist.png>. The browser
fails with a "Too Many Redirections" error.
When a path is not found, nor in the static files, nor in the
controllers, `_serve_fallback` kicks in and attempt to find a resource
outside of the router that matches the URL. In case it finds an
attachment with a matching URL, it'll deliver it.
In this specific case, it finds our attachment and return a redirection
to it's URL, which is the same URL as the request hence it loops back.
Don't deliver URL attachments via `_serve_fallback`, only deliver stored
files.
closesodoo/odoo#156323
X-original-commit: d2bea592db6a66d531b83437d42b273606f629f1
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
A new message type was added in stable. This is usually safe,
however in cases where there are related fields on that same selection
fetching them will raise an exception as the ORM has to fetch the translations
for the selection in DB.
We add a hack on mail.mail to update the selections in DB when fetching
the message_type field for the first time.
task-3773301
closesodoo/odoo#156235
X-original-commit: 19683173708a2b029acb4e744871772b6c248715
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
**Current behavior:**
A survey question which has a comment field counted as an
answer will not reveal its text box input field when it is
selected as the current answer.
**Expected behavior:**
After clicking on the comment field answer, the text box will be
revealed and enabled.
**Steps to reproduce:**
1. In the surveys app, add a question to a survey of type
`Multiple choice: only one answer`
2. In the question's options, enable the `Show Comments Field`
and `Comment is an answer` options
3. Go to the question in the survey, click on the comment answer
and observe there is no field to enter a comment
**Cause of the issue:**
The function which is responsible for adapting these page
elements is not selecting the correct html elements, thus their
attributes are not properly changed when needed.
**Fix:**
Change the function variables so that they are pointing to the
correct location in the DOM.
opw-3748291
closesodoo/odoo#155023
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
When a user has only "User" right for point of sale and no other access
some functionalities are not working properly. For example, the user
cannot create an invoice from the PoS interface. And the user cannot
use the "Ship Later" functionality.
Steps to reproduce:
- Change the right of a user to "User" for point of sale and no other
access.
- Log in as this user and try to create an invoice from the PoS
- Try to use the "Ship Later" functionality
Note:
This commit modify the access right of the test pos_user so that it has
the minimum access to be able to use the PoS interface properly.
opw-3644739
closesodoo/odoo#153104
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit when duplicating a warehouse, its operation types (picking.type)
wouldn't get copied. This commit ensures that new picking.types are created for
the duplicate warehouse.
[Reproduce]
- run odoo 17 with -i stock,mrp_subcontracting
- in Inventory/Configuration/Warehouses Duplicate a Warehouse
- Bug: in Inventory/Configuration/OperationTypes picking types aren't duplicated
opw-3674614
closesodoo/odoo#151769
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Description of the issue:
Before this commit, allocation created for which
no nextcall were set (allocation starting in the past
or immediately) would update to a wrong value if the
cron is run immediately after the allocation creation
To reproduce the issue:
- Create an accrual plan giving daily allocation
- Create an allocation with that accrual and a start date
in the past
- Validate the allocation
- Run the accrual schedule action manually
- The new amount for the allocation is inferior to what it
was at creation
Expected Behaviour:
The value should remain the same
Fix:
A nextcall is now set whenever the allocation is supposed
to have already started to ensure no immediate accrual update.
closesodoo/odoo#148154
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Bug
=====
Click the `preview` button on the course page. It does not apply the proper styles
to the button used for enabled or disabled content previews.
Technical
===========
With commit https://github.com/odoo/odoo/commit/2d386bc437194b78ea5d446d7b0fa4f5444406e2, the `badge-hide` class used for the `preview` button was
replaced and some styles were altered.
After this commit
==================
The `preview` button is functioning properly.
Task-3751285
closesodoo/odoo#156409
X-original-commit: 0dd6eba169b17d02f0b8a2b6fbcd8963db75d292
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Bug
===
When we show a PDF in e-learning, we have some navigation buttons
(next, previous, last, first) with some conditions for them to be
enabled or not (e.g. a documentation can have suggested slides, and
so the next button is visible even if we are on the last page).
Those conditions are broken (sometimes a button is disabled when it
shouldn't and vice versa), this commit aims to fix that issue.
Task-3751253
closesodoo/odoo#156363
X-original-commit: f22ef44fc509e4dc1c75fbde54027bf8104c54e6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Reduce the log size in case of failure of a screencast frames
Avoid a race condition while removing tree.
closesodoo/odoo#156341
X-original-commit: 97dc741929eb9497f9b44c110607254f0a873698
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
**Issue Description**:
Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not manually adjusted, leading to each tax having an identical sequence value. As a result, their hierarchy within the `flatten_taxes_hierarchy` function is determined by their input order rather than a defined sequence, causing unpredictable tax calculations.
https://github.com/odoo/odoo/blob/56666f8f7858fcbcce466d2240135b35509d2d96/addons/account/models/account_tax.py#L611-L632
A tax sequence should be explicitly defined, and in cases where sequences are identical, organization by tax ID should be enforced.
**Steps to Reproduce**:
1. Navigate to the `Account` or `Invoice` application.
2. Go to `Configuration > Taxes`.
3. Create a new tax with the advanced option `Affect Base of Subsequent Taxes` and specify an amount.
4. Generate a new invoice and add a line item priced at 100.
5. Apply taxes in the `Taxes` column in the following order: 15% followed by the newly created tax, and note the total amount.
6. Repeat step 5, but reverse the order of the taxes.
7. Observe that the total amounts differ between the two sequences.
**Proposed Solution**:
To ensure that taxes are applied consistently regardless of input order, we will modify the `flatten_taxes_hierarchy` function to add sorting by id. If the sequences are identical, the sorting will depend only on the id, otherwise it will be based on the sequence. This setting ensures a predictable and logical process for applying taxes.
opw-3691765
closesodoo/odoo#156337
X-original-commit: 4afc5657a112a1466bc9bfe5ca6c4a64cbdb717e
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
Steps to reproduce:
- Install website_hr_recruitment module.
- Go to Recruitment app.
- Click on Job Page button on one of the position cards.
- Click on Apply Now! button.
- Click on Edit in the upper right corner.
- Remove the LinkedIn Profile, then save.
- Click on I'm feeling lucky button to apply the form.
- An error is raised indicating that `Cannot read properties of undefined (reading 'trim')`
Investigation:
- the linkedin field is grabbed by `const $linkedin_profile = $('#recruitment4');`
- and then is used to check the condition `$linkedin_profile.val().trim() === ''`
- but since the field no longer exists, the `$linkedin_profile.val()` is undefined and hence the error is raised
The Fix
- The functionality is to allow to apply the form if at least one of the linkedin or resume fields is non-empty
- we a field as empty if it:
- doesn't exists
- exists but is value-empty
opw-3754506
closesodoo/odoo#155336
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Issue:
Infinite loop in Trial Balance.
Analyze:
The infinite loop is due to
account_reports.models.account_report.AccountReport.get_account_codes
`while group:` loop if a recursion exist in group.parent_id there is an
infinite loop.
Fix:
Ensure the no recursion constrains on parent_id in account_reports.
Related task:
opw-3665256
closesodoo/odoo#156410
X-original-commit: 0ce8efbc78853876b9768b6500a4998745ecc070
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Added a validation for URLs on product.document to resolve an issue
where incomplete links on documents will redirect to a local URL instead
of an external URL. Thus leading to a page that does not exist.
e.g.: youtube.com instead of https://www.youtube.com
This seemed like the proper course of action as there would be no reason
to not validate as any URL within the database can still be formatted properly and work the same.
api.constrains does not seem to work upon creation on this model, so I
opted to use the api.onchange.
opw-3698591
closesodoo/odoo#155806
Signed-off-by: Ryan Cen (ryce) <ryce@odoo.com>
Co-authored-by: Morgane Demesmaeker (edm) <69820391+Demesmaeker@users.noreply.github.com>
Before this commit, when importing product template attribute exclusions,
variants were not updated accordingly.
Now, variants will be created, archived, or deleted when creating,
modifying, or removing exclusions.
opw-3693065
closesodoo/odoo#156339
X-original-commit: 95c4223700a8049d4eb181d837f0b7f743269ec0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
closesodoo/odoo#156307
X-original-commit: d2e473f5b2b1b0fa1eae0f2a1e3698d663af07d8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-When product in combo choices are being archived because of variants creation, replace the archived reference with all newly created variants.
-Add test to reproduce this use case
task id: 3713861
closesodoo/odoo#156301
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Set Rounding Method to "Global rounding"
Create a sale order having these line values:
- Price Unit 54.45, tax 10% not included
- Price Unit 600.00, tax 10% not included
- Price Unit -500.00, tax 10% not included
Tax total will be:
Untaxed Amount 154.45
Taxes 15.44
Total 169.89
From the Sales Order create the Invoice
Issue:
Invoice tax totals will be
Untaxed Amount 154.45
Taxes 15.45
Total 169.90
This occurs because when managing the rounding errors for global
rounding the system 'force' a 1 cent difference on the negative line
that do not need rounding
Example:
Line 1
- current diff: 0.0
- computed tax amount: 5.455
- tax amount + diff: 5.455, after rounding: 5.45
- stored diff for next line: -0.005
Line 2
- current diff: -0.005
- computed tax amount: 60.0
- tax amount + diff: 59.995, after rounding: 60.0
- stored diff for next line: -0.005
Line 3
- current diff: -0.005
- computed tax amount: -50.0
- tax amount + diff: -50.005, after rounding: -50.01
A solution is to not add the diff when the tax line is already rounded
opw-3715229
closesodoo/odoo#156016
X-original-commit: bbca871841577203e44c98290ab0087ec94cf521
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Co-authored-by: smetl <las@odoo.com>
Steps to reproduce:
- Install point of sale and accounting
- Create a branch
- Make a copy of the outstanding receipts account and change company to
the branch
- Attach the branch to this account in the accounting settings
- Open a PoS make a transaction and close the session
Issues:
An error is displayed notifying the user that the journal entry draft is
not valid.
Solution:
Accounts that are attached to a branch should be valid for them as well
as their parents account.
opw-3659707
closesodoo/odoo#148810
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Each payment acquirer has its own implementation specificities: some
implement a 'payment with redirection' flow and others a 'direct payment
flow'; sometimes the 'payment with redirection' flow is even implemented
as a 'direct payment' flow through an iframe; one payment acquirer could
support webhooks while another does not and relies on another mechanism
to fetch payment status updates...
It can be tricky to guess where to look in the code to determine how a
payment acquirer is implemented.
On top of that, the online payments ecosystem evolves at a fast pace due
to competition, buyouts, and legislation enforcement. Acquirers are thus
frequently migrated to new APIs that might differ in implementation from
the previous API.
To help figure out the *which*, *why*, *how*, and *when* of payment API
implementations, a README.md file is added to the main directory of all
payment acquirer modules. They can be browsed in human-readable format
on GitHub.
task-2374916
closesodoo/odoo#156084
X-original-commit: 4c19f26df3d39394cce2f183d6df15c5b89c7d27
Related: odoo/enterprise#57921
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, if a product had a discount applied in two
different orders, it could lead to incorrect calculations in the report
For instance, if a product priced at 14.45 had a 30% discount applied,
the discounted value would be 10.115, which rounds to 10.12. However,
if there were two orders with the same discount, the report calculation
would count the quantity of a product with the same discount and
calculate the product total amount in one place. This would result in a
discounted value of 10.115 * 2 = 20.23, while in the two different
orders we had two 10.12 which sums to 20.24.
With this commit, the calculation method has been changed. Now, the
product amount total for each line is calculated first, and then the
sum of these amounts is used to calculate the total for all of the
orders. This change ensures accurate computation of the product total
sum when discounts are applied across multiple orders.
opw-3721376
closesodoo/odoo#156160
X-original-commit: bb71f77e117a8a07c1e161f583d136cd5c16a078
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
When listing jobs on the website, we show the number of open positions.
Currently the "open positions" were crafted in the QWeb template in such
a way that the translation mechanism couldn't extract it and thus it
could not be translated.
In this commit we fix that, so that it can be translated again.
opw-3761288
closesodoo/odoo#155974
X-original-commit: d19aa2e13be11cb2ce9d293c453a58f136b03712
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Current behavior:
When invoicing a POS order, the payment were not appearing in the
invoice.
Steps to reproduce:
- Create a POS order
- Validate and invoice the order
- Open the invoice PDF, the payment is not appearing
opw-3748596
closesodoo/odoo#155771
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Bug
===
Since c5b87e130b , the Date / Datetime
are not formatted the way they suppose to be. So the value is not
correct (it contains the timezone, etc).
Because of that, the string "Invalid Date" is stored in database
instead of "YYY-mm-dd" when we change the default value in the
definition.
Task-3774178
closesodoo/odoo#155749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fix race-condition when a directory is created by two processes (python's os.py
handles it for all directories, but not for the last one). Happens sometimes
when generating assets for the first time (CSS, JS); one of the two times might
crash.
sentry-4417110945
closesodoo/odoo#156232
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
This commit resolves an issue (arose in [1]) where a select field was
displaying IDs instead of labels.
Steps to reproduce:
- Navigate to edit mode
- Drop a form block.
- Select the form action type "create customer" (CRM app must be
installed).
- Add a field for "country".
- Add another field and set its visibility to depend on the country
value.
Issue:
Users are seeing IDs instead of country labels.
[1]: https://github.com/odoo/odoo/commit/a54f11edb1f81c8dade2a4ef6080b666b94e918d
task-3460326
closesodoo/odoo#156190
X-original-commit: 00c9df80fb89e5f50ada256b648a678fe8e0ce15
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
The commit 7452f855f05251a5458ddb4d654b03be1b179d40 was fixing the
problem in a simple way. It however wasn't good enough of a fix as we
discovered we were triggering too many onChange after the forward port.
So we revert commit 7452f855, and backport 5ffc604 from 17.1. It adds
a method on the model to reset the validity of a field.
It was not what felt the best, but as it is working and we just want to
fix the problem in stable, we go for it.
opw 3680495
closesodoo/odoo#156139
X-original-commit: 2fa3fd751a968a15a76d322c53241022b4b18ef3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps to reproduce:
- In website edit mode, have a header with a search icon
('default header').
- Add a few building blocks, enough so that you can scroll.
- Save the page.
- Scroll down until the header is back to fixed on top.
- Click on the search icon.
- Bug: the search bar appears in header (instead of below it, like at
the beginning).
This issue occurs because when the header is fixed and has a 'transform:
translate' property applied, the search modal, which is positioned
absolutely, takes the dimensions of the header instead of those of the
body.
To resolve this, we relocated the '#o_search_modal' element from the
'#header' to '#o_shared_blocks'.
task-3646513
closesodoo/odoo#155703
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When having reconciled a payment with an invoice
after having changed the outstanding receipts account
on the bank journal, we get an error when unreconciliing
the payment and the move.
Steps:
- Create two new outstanding receipts accounts X and Y
- Set X as outstandings receipts account on the Bank journal
- Create a manual customer payment P for $100, confirm
- On Bank journal, change the outstanding receipts account from
X to Y
- Create and confirm an invoice for $100
- Reconcile with payment P from the widget
- Unreconcile or reset invoice to draft
-> Error: "Journal Entry %s is not valid. In order to proceed,
the journal items must include one and only one outstanding
payments/receipts account."
opw-3659092
closesodoo/odoo#155558
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- Go to a website page (in "edit" mode) > Add a "Text Image" block > Add
other blocks before and after the snippet so you can scroll the page
content.
- Scroll in a way that makes only a part of the image visible.
- Select the image and click on the "Crop" button > The crop widget is
applied to the image in its current position (partially visible), which
makes it impossible to crop it correctly.
The goal of this commit is to prevent the issue described above by
simply scrolling to a position that allows to correctly edit the image
before applying the crop widget and also allowing the widget element to
scroll when trying to crop an image that overflows the current viewport.
task-3420186
closesodoo/odoo#155094
X-original-commit: 8ef34c15336c6938f40c15dbcc64c025b24d5808
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
How to reproduce the bug :
- Go to one project from portal user
- Open a task
- Create a subtask of this task
- Open the subtask
- Click on "Parent Task" button
=> Traceback
Fix :
- The search view is not loaded when opening the parent task
- We add manually the search view id in the action opening the
parent
taskid:3551354
closesodoo/odoo#156183
X-original-commit: 536638a92d6d7b242e27ae6f73431c61267b4eeb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When inlining styles for e-mails, some styles could be lost if they were
defined in css but also had an inline style that started with the same
characters. For example, a node with a style attribute defining
`margin-top: 10px` and a css style defining `margin: 5px` would end up
with `margin-top: 10px` and losing the rest of the information.
opw-3650141
closesodoo/odoo#156177
X-original-commit: f2d2531125af90bd2a20e0e1a5cb5e44e7b4a02b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Alvaro Fuentes