Steps to reproduce:
- Create a PO (fifo automated product)
- Recieve product
- Create the bill and add the landed cost product to it
- Create the landed cost before posting the bill
- Post the bill
Bug:
when creating the landed costs if the bill is already posted
the created amls are reconciled otherwise they aren't
Fix:
reconcile the landed costs amls after posting the bill
opw-3377088
closesodoo/odoo#134170
X-original-commit: 07666e46b658dd9c55abfcd2d94f1c033ac9c04f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
from the last commit (https://github.com/odoo/odoo/pull/133986)
we not allow pi user to execute timesyncd script
This fix allow pi user to execute timesyncd script at the boot
closesodoo/odoo#134145
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Commit 72a17bafba6e7 force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.
Instead, this commit patch the call to `_select_seller` to take at least
`today()`
closesodoo/odoo#134130
Opw: 3167094
X-original-commit: b06b0a77bcac6c5289e957e5133d6a213d68948d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce
============
* referrals -> configuration -> rewards
* try creating a new reward keeping description empty
* here description is required html field
* traceback on clicking save
Problem
=======
in case of html field, `this.data[fieldName]` is an object `Markup{''}`,
so `!this.data[fieldName]` is always `false` as objects are considered
as true value in JS.
Solution
========
in case of html, check the length of the Markup object
opw-3469539
closesodoo/odoo#134119
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Niyas Raphy <https://github.com/niyasraphy>
Current behavior:
When settling an order, the manually_set_price field is set to true
when it shoudln't. This cause issues in the french localization, as it
was always showing the current price as the old price.
Steps to reproduce:
- Install the l10n_fr_pos_cert module, and pos_sale
- Create a new order, add a product and confirm the order
- Open the PoS
- Settle the order you created
- The current price is shown as the old price
opw-3440797
closesodoo/odoo#133382
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
It can be that the name field on the account_move_line is an empty
string (as opposed to NULL). This can happen, for instance, when
generating the payment term line for Switzerland without the appropriate
fields on the company.
Since there are instances when the payment term's name is an empty
string, we can retrieve these lines and automatically match them with
payments from the bank reconciliation model. This can happen
automatically, with exact matches between a payment with a near-empty
reference (when the payment ref is just "/" or "?", this is sanitized
and ends up as an empty string for the purposes of comparison), and
these empty string payment term invoice lines.
The query that fetches the candidate lines for exact matches already
excludes those lines with a NULL move_line name, move ref, move name.
The natural extension of this behaviour is just to exclude the empty
string in these queries also.
closesodoo/odoo#133005
Signed-off-by: Laurent Smet (las) <las@odoo.com>
before this commit, on inheriting the function
_get_custom_rendering_context_values the argument values are not received
in the inherited function as it is not passed along with the super
scenario:
* consider that the payment link is shared to customer
* customer made the full payment
* once the sale or invoice is fully paid, the link has to
be shown as fully paid or expired
* for doing this, if we inherit the above function, the
arguments is not passed to the function
after this commit, the argument values are passed to
super and the value can be used re used in the further
inherit of this function
closesodoo/odoo#134088
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
- Install `website_sale`
- Go to settings
- Enable 'Comparison Price'
- Go to products
- Open a random product
- Put a random `Compare to Price` (example $400 with a sales Price to $295)
- Click on smart button `Go To Website`
With $ 1 = 0.5 €
Before:
With `Public Pricelist`: `$ 300.00 ($ 400.00)`
With `EUR` pricelist: `150.00 € ($ 400.00)`
After:
With `Public Pricelist`: `$ 300.00 ($ 400.00)`
With `EUR` pricelist: `150.00 € (200.00 €)`
backport of https://github.com/odoo/odoo/pull/87134closesodoo/odoo#133484
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
When adding a view to the dashboard, we already save the domain.
We don't want to save the default filters as they can have an opposite
domain as the one selected, meaning no records will be matched when
going to the dashboard.
---
opw-3385248
closesodoo/odoo#132328
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Changes in default can be bothersome, embed a full baseline
configuration for reliability.
closesodoo/odoo#27926
Signed-off-by: Pierre Masereel <pim@odoo.com>
Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.
Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B
Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report
You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)
opw-3171295
closesodoo/odoo#133676
X-original-commit: 9bdb0ed25dcef3f651a65abf0c4a8d9ce4e27851
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before this commit, when restarting a synchronization with Outlook or Google, a traceback error could be thrown due when accessing a variable possibly null. After this commit, the variable integrity is checked before its access.
Issue from: 3473180
closesodoo/odoo#133991
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).
What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.
Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).
closesodoo/odoo#133959
Reported-by: @rezak400
X-original-commit: fd353d7d0104431208b91603431e41ef4a6e54bb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Accounting moved the logic of _get_reconciled_vals
into _compute_payments_widget_reconciled_info but did not made the
change in point_of_sale.
This commit resolve this by putting the logic of the previous
_get_reconciled_vals into an override of the
_compute_payments_widget_reconciled_info method.
This is done because this is a legal requirement in France to have and
maybe in other countries.
closesodoo/odoo#133655
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Since [1] if the partner related to a visitor belongs to a company that
cannot be accessed by the current user, an error is raised when trying
to display the list of visitors.
This commit makes the name obtained through an additional sudo on the
`partner_id` record which might not be accessible to the current user.
This is equivalent to using the `name` field of visitor, except that
accessing the `partner_id` field will fail if `website.visitor` itself
cannot be accessed.
Steps to reproduce:
- Go to Settings / Companies
- Create a second company
- Go to Website / Reporting / Visitors
- Select "Edwin Hansen"
- Navigate to its linked partner in the contact field
"Gemini Furniture, Edwin Hansen"
- Navigate to its company "Gemini Furniture"
- In the "Sales & Purchase" tab, assign the second company as the
Company
- Save (this creates an error - but it is saved)
- Go to Website / Reporting / Visitors
=> The page was not displayed and an access error message was
displayed.
[1]: d348bed1ad
opw-3462104
closesodoo/odoo#133553
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the optional column "Product Variant" is enabled on
the sales order lines tree view, if the variant of a
configurable template is given, the configurator was triggered
and opened when it shouldn't have, since the variant is already
chosen.
Backport of de7a6f5f3d83356eb02f8fc25b4a0b8aabb946b3 in 16.0+
Fixed in 16.3+ by the forward-port, but not in the base commit.
task-3397870
opw-3450317
closesodoo/odoo#131574
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the problem:
- Go on the "Courses" application and select a course.
- Edit.
- Replace the main image of the course with one of your own.
- Save.
-> The function route `/web_editor/modify_image/` is called two times
leading to the creation of two attachments instead of one.
The `saveModifiedImages()` function iterates through editable elements
and calls `/web_editor/modify_image/` for each image with a
`o_modified_image_to_save` class inside those elements. In our case, the
image has an editable element parent that has itself an editable element
parent. Because since [1], the `o_modified_image_to_save` class is
removed after the `rpc` call, this class is not removed while the
`saveModifiedImages()` loops on the second editable element parent of
the image. As a result, `/web_editor/modify_image/` is called two times.
Note that before [1], the process was partially wrong as well.
`/web_editor/modify_image/` was indeed called only once but with the
wrong arguments. This is now fixed by ensuring that the function is
called with the arguments coming from the closest editable element.
[1]: 8872aab2d1
task-3451349
closesodoo/odoo#130472
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
New module is created (`l10n_it_edi_pa`) to add fields that are required to handle Split Payment, and it will be merged in master.
- `l10n_it_origin_document_type`
- `l10n_it_origin_document_date`
- `l10n_it_origin_document_name`
- `l10n_it_cup`
- `l10n_it_cig`
These fields are required to track money used that comes from funding to the Public Administration business for purchases, be it ordinary or project based spending.
They also need to be exported in XML during the EDI phase, in different
XML nodes depending on the `l10n_it_origin_document_type` field
ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiOrdineAcquisto
Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645
Part-of: odoo/odoo#132026
When an Italian company bills a PA business (for example they're selling cleaning services for a public building) the PA business will send the VAT to the Tax Agency themselves, while generally the VAT is collected and sent to the Tax Agency by the buyer (the PA business). This is done to avoid VAT fraud as the PA doesn't trust the business will actually pay the VAT. That's very common in Italy.
A new module will be created (`l10n_it_edi_pa`) in the next commit to add fields that are required to handle Split Payment, and it will be merged in master.
- New Split Payment related accounts are created: 2607, 2608
- New tax report data to target the VE tax chart grid
- Split Payment account.taxes are Groups of Taxes whose children target VE38 tax grid
- account_tax's l10n_it_vat_due_date is no more, we base ourselves on the VE38 tax grid
- The Group of Taxes includes normal VAT and a reversed VAT entry (for sale)
- Tax checks on the invoice now also check group of taxes with flatten_taxes_hierarchy()
- New Split Payment tax group has been added to build the correct totals in the move form view
- account.taxes and account.fiscal.position has been added to change from VAT to VAT Split Payment automatically when you select a res.partner that features the fiscal position.
- The Fiscal Position also has the law-required note that has to be featured on invoices that use Split Payment
- A PA business demo partner is added to showcase the new fiscal position
- `l10n_it_stock_ddt` tests are minimally modified because the Form component didn't let you use 'like' in the move form view
Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645
Part-of: odoo/odoo#132026
Steps to reproduce:
- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.
Current behaviour:
The generated work entry mismatches the value of the attendance
Expected behaviour:
The work entry should match the attendance
Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.
However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.
task-3468012
closesodoo/odoo#133610
Related: odoo/enterprise#46574
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Issue:
======
- Display of monetary values in kanban views is wrong in rtl language
- Pivot display has multiple erros in rtl language: values are left
aligned and they are supposed to be right aligned like in ltr lang,
negative numbers has the sign in the wrong place, the (plus/minus)
icon placement is wrong (it should be before the title and not after)
Steps to reproduce the error:
=============================
- Install accounting and rlt language (arabic for example)
- Go to accounting (display of monetary fields is wrong)
- Go to accounting/accounting/journal items/pivot view
- Choose residual amount in view (it has some negative values)
Solution:
=========
Kanban Solution:
- I fixed the direction of the display to be ltr always for monetary
values and added the class to the appropriate tags.
Pivot Solution:
- I fixed the direction and text-align style for the values to always
display the same like rtl.
- displaying the icon and then the title will always give the desired
display since the direction will reverse their order itself when it's
rtl
enterprise fix : https://github.com/odoo/enterprise/pull/46675
opw-3295573
closesodoo/odoo#132843
Related: odoo/enterprise#46675
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
This commit allows you to change the title of the social media block
after the first save. If an element is in a parent that has the class
`o_not_editable` then it is only editable if it has the contenteditable
attribute set to true. We rightfully remove this attribute at saving but
without putting it back when we return to edit mode. This commit allows
to fix this case. Note that we have to improve this system in the future
(so we can get rid of this patch).
This part of the fix is very similar to [this other fix] for the team
block.
[this other fix]: b7d53d2fcb
task-3073171
closesodoo/odoo#133860
Part-of: odoo/odoo#105964
X-original-commit: ba485b12bf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit allows you to change the icons of custom links of the social
media block after the first save. Thanks to [this other commit], there
is now a class that permits to inform the editor that a media is
editable even if it is a non-editable parent. This commit permits to use
the new class to fix the issue.
Steps to reproduce the bug:
- Drop a social media block on a page
- Add a custom social media
- Save
- Edit
- Try to change the icon of the custom social media with a double-click
=> The icon cannot be changed.
Note that [another commit] had already been made and fixed the problem
halfway (the icon change didn't work on double-click). This commit
reverts it and fixes the problem correctly with the new system.
[this other commit]: 6ead397f33
[another commit]: bb291b35e4
Fixes https://github.com/odoo/odoo/issues/104048
task-3073171
X-original-commit: a46a8f45b6
Part-of: odoo/odoo#133860
Current behavior:
When a discount is applied to a product, the receipt shows the price
with the discount applied as the base price.
Steps to reproduce:
- Open PoS
- Add a product to the order
- Apply a discount to the product with the numpad
- Validate the order
- Check the receipt, the base price of the product is the price with the
discount applied.
(https://github.com/odoo/odoo/assets/32939472/eb0998a7-70a1-432a-8909-868d9307c999)
The price in red should be 70$ (the price without the 5% discount)
opw-3463745
closesodoo/odoo#133835
X-original-commit: 07b08a2de0fb96dbecc398140acbe56a689e5b41
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
The commit f5ce6c5979 introduced a regression that prevents closing
a POS session if the user does not have accounting and inventory
access rights.
opw-3487462
closesodoo/odoo#133899
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Users sometime want to rename existing controllers URL, e.g. /shop as
french /magasin. The feature is possible within Odoo thanks to 308 type
redirections that can be configured via a hidden ?debug=1-only website
menu.
Upon generating the routing-map (the structure that links URLs to
controllers), when a URL is found inside of the `website.rewrite` model,
two links (called Rules in werkzeug jargon) are registered: the new,
translated, URL is linked to the controller and the original URL is
linked to a redirection to the new URL.
For the context of this PR, it is important to note that the redirection
only applies to the very URL saved inside the `website.rewrite` model:
if a controller has multiple routes, e.g. `/shop` and `/shop/shop`, only
`/shop` is redirected to `/magasin`, `/shop/shop` is left as-is.
Without 308 redirection:
/shop -> def shop()
/shop/shop -> def shop()
With 308 redirection:
website.rewrite(from_url='/shop', to_url='/magasin')
/shop -> /magasin
/shop/shop -> def shop()
/magasin -> def shop()
The redirection is set on the routing dictionnary of the endpoint, this
is the dictionnary that collect the informations set via the `@route`
decorator (auth=, method=, type=, ...).
Prior to [HTTPocalypse], that dictionnary was duplicated so that the
redirection was applied on the single route endpoint that matched
the `website.rewrite` record. With [HTTPocalypse] that duplication has
been wrongly removed: all original routes redirected to the new
translated one.
Bug introduced in [HTTPocalypse]:
website.rewrite(from_url='/shop', to_url='/magasin')
/shop -> /magasin
/shop/shop -> /magasin <-- wrong
/magasin -> def shop()
This PR fixes the problem, it makes sure that the redirection is saved
*only* on the route that matched the website.rewrite record, not the
other routes.
[HTTPocalypse]: https://github.com/odoo/odoo/pull/78857closesodoo/odoo#133371
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces a test in Odoo 15 about a broken behavior in Odoo
16 which was not covered by a test.
A fix will be shipped alongside this commit forward-port in Odoo 16.
The behavior involved here is about:
- Having a multi-url defined route
- One of those URL not having a model converter
- One of those URL having a model converter
- Creating a 308 redirect for the URL without model converter
Something like this route (real example from the code):
```py
@http.route([
'''/shop''',
'''/shop/page/<int:page>''',
'''/shop/category/<model("product.public.category"):category>''',
'''/shop/category/<model("product.public.category"):category>/page/<int:page>'''
], type='http', auth="public", website=True, sitemap=sitemap_shop)
```
And this redirect (real usual example from clients):
```py
self.env['website.rewrite'].create({
'name': 'Test Multi URL 308',
'redirect_type': '308',
'url_from': '/shop',
'url_to': '/magasin',
})
```
In Odoo 15, everything will work as expected:
1. Accessing /shop will redirect to /magasin
2. Accessing /shop/category/categ-1 will not redirect and user will be
on /shop/category/categ-1 still
But in Odoo 16:
In the case described above, acessing the URL with model converter from
the route will fail and redirect to a non slugified URL in the form of
`/some-url?param=test.model%287%2C%29` which is basically the
stringified encoded version of the record `test.model(7,)`.
Note:
- It doesn't matter if the route is contained in the other, the error
will still occur even if `'''/shop'''` was `'''/abc'''`.
- Even if all URL from the route have their own 308 redirect, the error
will still occur.
- It won't have any issue if there is a 308 on the route with model
converter: both the one without model converter and other url with
model converter will work and won't be impacted.
This might be because of a concept of "merging URL" from httpocalypse,
see 347a3ccf76
opw-3450054
opw-3466498
opw-3477380
opw-3475694
X-original-commit: 9230f7db60b10ca2a3e83d6beefb6cf72d09a804
Part-of: odoo/odoo#133371
Steps to reproduce:
1. Create an SO with billable timesheet entries
2. Create an invoice
3. If using enterprise, first cancel the invoice and reset the timesheet
entries back to draft, then set the invoice back to draft
4. Remove the sale order items from the timesheet entries
5. Remove the invoice line associated with the timesheet entries
Current behavior:
- Throws an error since the so_line value from read_group is now
False and is not subscriptable
Expected behavior:
- Removes the invoice lines
Fix:
- Check that the so_line is not False before continuing with the logic
closesodoo/odoo#133864
X-original-commit: dde3079812b1aab2b017c31791b8b4c7bdf0fc3b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
------
When adding a file to an employee's work permit ("Private Information tab"),
the file name is the "value" of the file.
This is not meaningful for the user who will download the file.
Solution:
---------
Use the `filename` attribute to determine the field of `hr.employee`
to be used to get the file name.
As the original file name doesn't exist in an existing field,
we can use a "generic" file name with a non-stored computed field.
opw-3458842
closesodoo/odoo#133569
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When sending a mailing we make sure to preserve comments (in particular
so that MSO comments can be read by Outlook). However this was not the
case when testing a mailing using the Test button in the form view.
task-3488162
opw-3290548
opw-3479234
closesodoo/odoo#133874
X-original-commit: d6568e0bf82e68ea0c36235d523913032b412af4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit fixes the issue of animations that got trigger by backspacing, pressing enter
and other causes
The cause of the issue was a custom historyRevert event that was only used to
trigger a widgets_start_request event which ended up restarting the options,
which lead to the animation option replaying the animation.
We were not able to pinpoint the use of this particular trigger_up as it does
not seem to serve any purpose anymore. Since its presence does create a bug, we
decided that the best course of action was to remove it. If this commit creates
a regression and the original bug comes back, we will reassess the situation.
Task-2752421
closesodoo/odoo#133806
X-original-commit: 16fc9e23adc2b91b163873293ccea99f4fb1850d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.
Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea4c) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.
Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).
Closes#127846closesodoo/odoo#133776
X-original-commit: 4dbc3b00e587f3d64cfd964a685f2bddd1b499ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This reverts [this commit]. Indeed, [this commit] was too restrictive on
the visibility dependencies and blocked the creation of some conditions.
Example:
- Add a form on the website.
- Add two fields and rename them (by "test" for example).
- Change the visibility of the first one and set it to "Visible only if
Your Name is equal to Boule"
- Change the visibility of the second one and set it to "Visible only if
Your Name is equal to Bill"
-> The field "test" will be visible if "Your name" is "Boule" or "Bill".
[this commit]: 17c93a4ca1closesodoo/odoo#133709
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
There were 2 errors fixed by this commit:
1. The form registry fields added in [1] and [2] in Odoo 13 had a
`string` attribute translated with `_t()` while now it should be
translated with `_lt()`. It was surely working in Odoo 13 but not
anymore. It's not worth investigating to be sure.
2. The IMP done at [3] added a lot of fields but all of those forgot the
`_t()`/`_lt()` translation.
Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
as it was not targetting the correct version... and only fixed one of
many occurences.
[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: 617eba9417
[4]: 2be83cae7b
opw-3471873
closesodoo/odoo#133692
Related: odoo/enterprise#46590
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug.
- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.
This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.
[1]: 2dcbfecf3c
opw-3449900
closesodoo/odoo#133689
X-original-commit: e4d64c9f4470874ca853bd871064bb8374c8b5cc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since a recent change at [1], a race condition seems to occur in the
gray colors palette test. Indeed, the change removed some delay in the
hackish code that is meant to wait for CSS reload.
Instead of restoring that otherwise-useless delay, this commit actually
fixes an extra_trigger that was incorrectly made in this test when it
was introduced at [2].
In any case, we should develop a more consistent and uniformed way to
wait for a CSS reload during edition test tours. It is currently done
different ways in different tests.
Note: this targets 16.0 to fix the wrong extra_trigger at the source,
even though [1] was only made in later versions.
[1]: c6f8f78115 (diff-795af7752739f5f510f74e5ee9b5b04d18a851062a1a6b7350cbe406e30a409dL18)
[2]: ddf2e74b4c
runbot-24371
closesodoo/odoo#133345
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the customer tries to move the video to the first position of the product
image. at that time, the error would be generated.
step to reproduce:
-Install the website_sale
-open Invoicing > vendors > Products > open any Product
-open sales Notepage
-click on add a Media
-past any video url > save it
-click on Go To website from the state button
-click on Edit button > again double click on the image
-then click on a right side position of re-order
error- Key Error:'video_url'
After applying our commit, if the customer got a validation error when
the customer attempted to swap the video into the product images at
the first position. There is a controller named
`/shop/product/resequence-image` which called, when the customer
changes the position of the video.
3ce90ddf33/addons/website_sale/controllers/main.py (L582-L587)
The `image res_model` will then receive the `product.image` model when a
customer moves a video from the third to the second position, and that model
locates the field known as `video_url`. However, when a customer moves a
video from the second to the first position, `image res_model` will then
receive the `product.product` model, and that model finds the same field but
does not have that field in it.
sentry-4393257638
closesodoo/odoo#132471
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Quotes need to be escaped otherwise it raises "unescaped double quote
found".
closesodoo/odoo#133741
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
During 'l10n_eg_eta' server connection when the
'request_response' is not in proper json format then
while decoding 'request_response', the user will face the
'JSONDecodeError Expecting value: line 1 column 1 (char 0)'.
We are keeping the 'blocking_level' as 'error' because the
occurence of this error will prevent the succession of ongoing
operation.
Applying the changes will resolve the issue.
sentry-4220714667
closesodoo/odoo#133735
X-original-commit: a3bb6ecebaf11bbfbda6c5c58614b9cd07f372ee
Signed-off-by: Josse Colpaert <jco@odoo.com>
Crop widget is implemented as div block that is supposed to be displayed on top
of other elements. However, it's not the case for dialogs, because they want to
be on top as well (z-index of dialog is 1050 bootstrap [1])
STEPS:
* Go to Sales Order
* SO
* Schedule an activity
* Use '/' command
* select image
* click image
* crop image
BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up
Fix it by increasing z-index for the crop widget
[1]: 9102df15cc/addons/web/static/lib/bootstrap/dist/css/bootstrap.css (L5524)
opw-3391583
closesodoo/odoo#133316
X-original-commit: 36c9b2b7916fbbdcfc912d652695699e50043edb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Current behavior:
The currency used to create the report is the one of the company. But
if you use a different currency in the pos config, the report will still
be in the company currency.
To fix that we check if all report's config use the same currency and
use it if it's the case we use the pos config currency. And if it's not
possible we use the company currency.
Steps to reproduce:
- Create a second pos
- Change the sale journal and the pricelist to use a different currency
- Open a session and make a sale
- Close the session
- Generate the daily report for the second pos
- The currency is the one of the company
opw-3463280
closesodoo/odoo#132852
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
a translation issue that only appears on Odoo.sh. On the
other systems and locally, everything works fine.
The problem seems to have its source in odoo.tools.translate
Here is the problem:
On the basis of staging (brutus), in the LIMS application, menu Report / Test reports:
* take report 000022. The client is in French.
* click on the button "preview PDF"
-> the values of the "state" column are not translated.
Locally (same sources, same database), these values are well translated.
This field is defined as follows:
```py
state = fields.Selection('get_state_value', string='State', copy=True, required=True)
def get_state_value(self):
return [
('init', _('Init')), ('conform', _('Conform')), ('not_conform', _('Not Conform')),
('unconclusive', _('Inconclusive'))
]
```
Here's what happens:
When the '_' method is called, another method ("_get_translation") is called.
It tries to determine which module is used. To do so, it is based
on the path (path) and use the "get_resource_from_path" method:
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L474
This method iterates over all defined addon paths. On Odoo.sh, these are:
```
'/home/odoo/src/odoo/odoo/addons',
'/home/odoo/.local/share/Odoo/addons/16.0',
'/home/odoo/src/odoo/addons',
'/home/odoo/data/addons/16.0',
'/home/odoo/src/user',
'/home/odoo/src/user/Logicasoft/base',
'/home/odoo/src/user/Logicasoft/lims',
'/home/odoo/src/user/Logicasoft/mail',
'/home/odoo/src/user/Logicasoft/web',
'/home/odoo/src/enterprise',
'/home/odoo/src/themes',
```
The path variable is equivalent to "/home/odoo/src/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
As soon as the 'path' variable has a common prefix with one of the paths in the
mentioned list, Odoo considers that it has succeeded in finding the path that contains the module in question.
Locally, the path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
And the found path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/"
But on Odoo.sh, the path found is: "/home/odoo/src/user/"
because Odoo finds that there is a common prefix. This is the case, but another path also has a common prefix: "/home/odoo/src/user/Logicasoft/lims" and this one is the correct one.
The result is that the module found is not the correct one:
- module='Logicasoft' on Odoo.sh
- module = 'lims_base' on other systems
Since the module is not the correct one on odoo.sh, the translation is not found.
Solution
========
when we have a module present in parent and child path we want to take the child path,
which is the long one, so we sort the list of paths by length which ensures that children
have priority on parents.
opw-3374757
closesodoo/odoo#132627
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.
closesodoo/odoo#133588
X-original-commit: 58c68c07f0fbb5a1a2bee410a7233904c1c66822
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Walid