Steps to reproduce
==================
In 17:
- Install hr_holidays,project
- Switch the language to dutch
- Go to project > three dots > Projectupdates
We can see `x/y Genomen`, it should be `x/y Taken`
Cause of the issue
==================
The original term is Tasks.
When loading the views, python translates them and changes Tasks to Taken.
Owl then translates the template and transforms Taken to Genomen.
Solution
========
Since the views are already translated, we don't need to translate them with owl.
We can simply set the attribute t-translation to off on the view root node.
opw-3787336
closesodoo/odoo#158627
X-original-commit: 454760e12145f8987e443d7776a614a5eb441feb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Current state:
- Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab.
- l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field.
- If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main tab but changes the visibility attribute of all the instances suit SK-based companies. However this means the field becomes hidden for CZ-based companies (current company). Plus the field is doubled if the current company is a SK-based one.
- A similar problem happens if the l10n_sk is installed first and l10n_cz comes after it.
Fix:
- Remove the invisible attribute so that the Company ID field on the main tab and on Sales and Purchase tab remains untouched and visible whatever the current company's country is.
closesodoo/odoo#158605
Signed-off-by: William André (wan) <wan@odoo.com>
In a multicompany setup when l10n_cz is installed after l10n_sk then the
Company ID field disappears from Contacts form view if current company
is not a CZ company (fiscal_country_codes != CZ). On the other hand if
the current company is a CZ company then the field is doubled in the
form view.
This change prevents the field from disappearing by reverting the
visibility condition change introduced by each of the l10n_sk and
l10n_cz module because they are clashing.
Part-of: odoo/odoo#158605
Before this commit, the header was considered as mobile at the `SM`
screen breakpoint, while it is already displayed as in mobile view at
`MD`. This made some of the header behaviors inconsistent and caused
some issues:
1) A menu open at `MD` is not closed when resizing the screen:
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
- Resize back at `MD`.
=> The menu was not closed. It is when we start resizing at `SM`, which
is inconsistent as they are both displayed like in mobile view.
2) Because of the first issue, we cannot scroll the page anymore after
opening the menu at `MD`:
- In edit mode, drop enough snippets to have a scrollbar and then save.
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
=> There is no scrollbar anymore and we cannot scroll.
This happens since PR [1], which redesigned the headers and changed the
"hambuger" menus so they open on the side (= offcanvas), and commit [2]
that prevented the `#wrapwrap` to scroll when these menus are open, to
prevent a bug on Safari. The issue happens because since the menu does
not close when resized, the class preventing the `#wrapwrap` to scroll
is never removed.
3) The menus are hoverable at `MD` but not at `SM`:
- Add sub-menus and mega menus with the menu editor.
- In edit mode, set the menus as hoverable (set the "Sub Menus" option
to "On Hover") and save.
- Hover the menus:
- above `LG` (= desktop view) => they open.
- under `SM` (= mobile view) => they do not open because we need to
click to open them on mobile view.
- between `SM` and `LG` => they open even though it is displayed like
in mobile view, so the behaviors are inconsistent.
4) Because of the third issue, there is sometimes a traceback when
hovering mega menus if the screen is at `MD`:
- Resize the screen at `MD`.
- Refresh.
- Open the menu and hover a mega menu dropdown.
=> There is a traceback sometimes.
Since commit [3], in order to avoid mega menu synchronization issues
between the desktop and mobile headers, the mega menus are not
duplicated anymore and they are moved from one navbar to the other when
opening them, so when hovering them if the menus are hoverable. A race
condition can happen in that case because the `hoverableDropdown` widget
tries to open the mega menu before the menu has been moved in its
dropdown, which causes a traceback. This seems to happen only when the
widgets start with the screen at `MD`, therefore, preventing the menus
to open on hover under `LG` prevents this race condition.
This commit considers the header as mobile under the `LG` screen
breakpoint, to fix these issues and to uniformize the behaviors of the
mobile header.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/389856bcd94d459d72f46c2a517afb3f6d976e38
task-3801970
closesodoo/odoo#158571
X-original-commit: 4d3c86cb33c12f0e7bbc7812452feb33ddfa8321
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Steps to reproduce:
- Install Invoicing (and Sales for product creation rights)
- From a company, create a Branch company
- Switch to parent company
- In Invoicing settings of parent company, set default taxes
- Switch to branch company
- In Invoicing settings of branch company, set no default taxes
- Create a user with only the branch company as allowed companies
- Give the user the right to create a product (e.g. Sales: Administrator)
- Connect with the created user
- Try to create a product
Issue:
An Access Error is raised due to "company rule employee" rule because
the system tries to fetch the default taxes from the parent company,
which is not activated in the company selector.
opw-3790360
closesodoo/odoo#158567
X-original-commit: 7a9088e2c76ac0309245bee8cf10863cd3ede19d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor.
Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened.
This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
closesodoo/odoo#158548
X-original-commit: b33086599383a4c0ab43126598a63e8721f682fc
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create a cron with an `interval_number` of 0 and change its nextcall so
that it is called soon. When the cron gets executed, the cron worker
enters an infinite loop during the computation of the next nextcall.
The cron now gets disabled with an error message. On the form view,
users now get a warning when `interval_number` is invalid.
closesodoo/odoo#158519
X-original-commit: aaf498ff2acf39f73fe408eab74e82a8d58f6f1b
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
There are currently translation issues related to the chart template.
Due to this the names of some records do not receive the necessary
/ intended translations when installing a localization or new language.
When installing a new localization / chart some records have the following
problem with the values of their translatabe fields:
They are only installed in the language that was active when the localization / chart was installed.
Thus when switching languages (or using a different user with a different language)
the names are displayed in the "installation language".
Translations for all active languages should be installed (for all relevant records).
The same problem happens when installing a new language
(the same records do not receive a translation for the new language).
The translation issue concerns for example (some) accounts and journals;
see the (incomplete) list at the end of this message.
This commit tries to fix the translation issue for the translatable
fields of all relevant models.
Note!
=====
* The translation mechanism only works for records with xmlid.
If a module creates a record without xmlid it will not be translated.
* The problem is only fixed for records with xmlid for which at least 1 of the
following conditions holds:
* The record (and the translatable field value) is defined in
the body of the function decorated with '@template'
* The translation of the value of the translatable field can
be found in the module 'account' or in the module that
is associated with the record (by 'ir.model.data')
I.e. the problem is not solved for demo data: It is technically
difficult to determine the module they originate from.
This makes it difficult to load the right code translation (the
module information is needed for this).
* The translation mechanism is not necessarily triggered
if the record is (in principal) part of the chart template
but not installed as part of the chart template.
This can i.e. happen if a module is installed after the
localization / chart.
* Example: account.journal "Salaries" from hr_payroll_account
* We also want to "translate" / localize some untranslatable fields
(like account journal codes). For these fields the terms will be
installed in the language of the partner of the company for which
the chart will be installed (fallback to lang / user lang from the
env in case there is none set).
* Currently there is no language set for many (all?) demo comany.
Thus the values will remain in English for them (when the
respective module is installed).
Examples / Details
==================
**Reproduce**:
1. Switch to the French language (install if needed)
(Settings App > General Settings > Languages)
2. Install a localisation (e.g. l10n_fr).
3. Check the French translations of the localization
* Comptabilité > Configuration (Menu) > Journaux
(Accounting > Configuration (Menu) > Journals)
* Here the journal names are in French
* Comptabilité > Configuration (Menu) > Plan comptable
(Accounting > Configuration (Menu) > Chart of Accounts)
* All the account names are in French
4. Switch to English on the current user (or some other language)
via the user profile on the top right.
5. Check the names of the localization again
* Accounting
* The journal names are still in French
* Accounting > Configuration (Menu) > Chart of Accounts
* Some of the account names are still in French
* E.g. "Compte d'attente de la banque" ("Bank Suspense Account")
Other things to test:
* "Salaries" journal from enterprise module 'hr_payroll_account'
* Not demo data; it will (partly) work after this commit (see "Note" above)
* "IFRS Automatic transfers" journal from enterprise module
'account_auto_transfer' (installed when installing l10n_fr)
* Demo data; the problem remains after this commit
**Technically** the main problems are the following:
1. The information of some of the created records is only defined in
the code. Thus their translations have to be taken from the
translation of the code.
But at the point of translation it is not clear from which
module the data came from. This is needed to load the right translation.
* This was fixed for data from '@template' functions
2. Some records are created without an xmlid and thus
cannot be translated with the current translation mechanism at all.
* This was fixed for the relevant records from module 'account'
Example Records
---------------
Some affected **accounts**:
* from module 'account'
* Bank utility accounts
* Bank Suspense Account
* Outstanding Receipts
* Outstanding Payments
* Cash Discount Loss
* Cash Discount Gain
* Cash Difference Loss
* Cash Difference Gain
* Liquidity Transfer
* Bank / Cash journal default accounts
* Bank
* Cash
* Unaffected earnings account
* Undistributed Profits/Losses
Some affected **journals**
* from module 'account'
* Customer Invoices
* Vendor Bills
* Miscellaneuos Operations
* Exchange Difference
* Cash Basis Taxes
* Bank
* Cash
* from module 'account_auto_transfer' (enterprise)
* IFRS Automatic Transfers
* The problem will remain since it is demo data
* from module 'hr_payroll_account' (enterprise)
* Salaries
* The translation is only loaded if the module is installed
before the localization / chart
task info
=========
task-3414329
closesodoo/odoo#158382
X-original-commit: bd6040fb8b1dee9efe0e461a6812ecf7acbb517e
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose of this commit:
Currently, people having access to different dashboards
without any access rights would end up with a traceback
when trying to search more employees.
Steps to reproduce this issue:
- have a user with timesheet officer rights and no hr rights
- log in with that user account
- go on the dashboard app and select "Timesheets"
- go on employee filter and click on "search more"
Current behaviour:
A traceback is displayed because the user has no access to the view
Expected behaviour:
The public employee search view should be displayed
How the issue was fixed:
The method called `_get_views` has been overriden in
the `hr.employee` model to return the `hr.employee.public` views
instead. As there was no way through the dashboard to define a
relation, the method explicitely takes the result for the
public employee and sets it as result of the private one as well.
closesodoo/odoo#158380
X-original-commit: 6e304037023545eb7eb453d5656f7e1769615d38
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Since [1] when options on background images have been applied as soon as
they were modified instead of on save, those options were not reset when
the background was removed.
This commit removes those options when the background image is removed.
Steps to reproduce:
- Drop a Text snippet.
- Add a background image.
- Remove the background image.
- Save.
=> Save failed.
[1]: https://github.com/odoo/odoo/commit/4a797f51ec9d3d378fc30033e4fda2bc1e73586c
task-3794812
closesodoo/odoo#158326
X-original-commit: 23c805030abb89ca449cf430d5661d725f5801a8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: Serge Bayet <seba@odoo.com>
There is a ir.model.access rule that allows `hr_expense_team_approver`
group members to read account moves and account move lines. Another
existing rule forces the domain to only read account move lines that
have an associated expense_id. This rule however is not repeated for
account moves, and thus an `hr_expense_team_approver` group user is able
to access unrelated Customer Invoices / Vendor Bills on the portal at
`/my`.
To fix this, this commit adds a rule to prevent the
hr_expense_team_approver from reading any move that does not have at
least one line with an associated expense_id.
TT48242
closesodoo/odoo#158323
X-original-commit: 869fb231deaa986e687749ba639123988ceebc66
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In the Point of Sale app, some terms were not translatable by our
translators on Transifex. In this commit we make sure that the missing
terms are either made translatable or exported in the related .pot file.
closesodoo/odoo#156929
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce:
1- Install Point of sale module
2- Allow shipping later configuration
3- Create a POS order with a shipping date
Current behavior before PR:
The expected shipping date was not printed in the pos receipt.
This was happening because it was getting called wrong in xml file
where it was called 'props.shippingDate'.
By checking the JS file we found that the props object structure
as follows https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.js#L16:L19
Desired behavior after PR is merged:
The expected shipping date is printed not if exists.
As we it is now getting called correctly 'props.data.shippingDate'
opw-3746053
closesodoo/odoo#155844
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
1. Install hr_holidays
2. Connect as Admin
3. Go to the profile
4. Check Handle in Odoo in Notification
5. In a private browser, connect as Demo
6. Go to Time Off
7. Take a day off
8. A push notification for Admin pops-up
9. The profile picture is wrong
Cause of the issue:
author_id is linked to res.partner not res.users
Fix:
Backport of: https://github.com/odoo/odoo/commit/1244c9c02d6242d34a37aa27168229e9d3939cb4
opw-3684987
closesodoo/odoo#155107
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit introduces an improvement in the hr_holidays module by
making the duration field of leave allocations editable even after they
have been approved. This change addresses a limitation where previously,
allocations had to be refused and revalidated for any adjustments.
Task-3716272
closesodoo/odoo#154553
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Address several design and functional issues in prod.
See sub commits, each of them addressing a different issue.
Task-3718417
part-of task-3698364
closesodoo/odoo#152434
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit sets the default container as `container-fluid` when
`option_widescreen` is enabled. The goal is to ensure that, regardless
by the desired result, Bootstrap grid layouts behaves consistently
within the page.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit allows the user to drop snippets before and after the
booth's selection page content.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Prior to this commit dropdown menus were badly affected by custom CSS
rules aiming to fine-tune the event submenu design.
This commit restricts the rule to the menu's direct descendant only.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_booth, website_event_exhibitor, website_event_meet,
website_event_track, website_event_track_live
This commit adjust classes to address readability across text and
decorative elements taking in account eventual customization applied by
the user through the editor.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Address several design/ux issue related to badges.
In some cases badges are too small, in others the badge should be
clickable while in others should not.
In some circumstances informative components like small alerts should be
used instead.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit simplifies the editing process of the "Talk Proposal" page
by applying `row` and `col` classes.
This enables users to adjust vertical spacing conveniently using the
editor.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Address a minor layout issue on desktop devices.
Note: "Stable friendly" fix. The 'booth_category.description' field
output, for example, should be moved outside the `card-body` element.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_exhibitor, website_event_meet, website_event_track
Previously, to expand a collapsed track, users needed to click the icon.
This commit introduces a CSS workaround that allows clicking or tapping
on the entire track header instead.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit handle an issue causing the registration inner elements to
don't overflow as expected when multiple tickets are rendered on screen.
Note: This could probably be improved by review the overall modal layout
in order to make a different use of Bootstrap default classes.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit addresses various minor responsiveness and design issues in
the "event registration modal." Additionally, it modifies the condition
for rendering prices range and to display it if more than two
tickets exist only.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_booth, website_event_exhibitor, website_event_meet,
website_event_meet_quiz, website_event_track
This commit refines headings throughout the entire `website_event`
platform by optimizing font-size hierarchy, spacing, and white-space
management for improved consistency and readability.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit addresses a scenario where users may prefer lowercase titles
over the default uppercase ones.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_booth, website_event_exhibitor, website_event_meet,
website_event_track
This commits address several minor layout issues across the entire
`website_event` platform.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit removes the "Fold Tickets Details" editor option that's
non-functional because the corresponding template no longer exists.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Ensure consistency in the positioning of the website_event's modal
buttons to align with odoo's standards.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit enhances the user experience by rewording editor options to
ensure predictability. Specifically:
- The use of the `o_we_sublevel_1` class was misleading as these options
are not tied to the main layout type.
- The term "Templates" was ambiguous, as the option actually renders
event's template badges.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Commit [1] made it possible to stay in the backend while refreshing the
page with F5 or CTRL+R when viewing a Website Preview. Pressing it too
fast when the page is still loading and the iframe isn't loaded yet
triggers a traceback.
This commit falls back to the default refresh in such cases.
[1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd
task-3795143
closesodoo/odoo#158314
X-original-commit: c81dfa7dda95a8d63b4abba9ce67d7f3e48af935
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Current behaviour before commit:
After selecting cells in table, moving cursor through
arrowkeys doesn't deselect cells.
Desired behaviour after commit:
Now cells are getting deselected.
task-3718716
closesodoo/odoo#158265
X-original-commit: 0e8865e06b3cb7e8ee1a2c4983d06baef5b30933
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Adnan Saiyed (adsa) <adsa@odoo.com>
- Remove context which came from the calendar action to only show short name in activity message
- Replace date connector with - as a / does not help to better understand the data given
closesodoo/odoo#158220
X-original-commit: 125793980e10f0c7d186f5662e4abbb3de3e212a
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Steps to reproduce:
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components
The MO overview of a FP shoud look like this :
FP
/\
/ \
P3 P2
| |
P2 P1
|
P1
- Create and confirm a manufacturing order for a FP
Current behavior:
As the quantity on hand is not sufficient to manufacture a FP,
manufacturing orders are automatically created for P3, P2 and P1.
However, the quantity on each of these MOs is of 1 unit.
Expected behavior:
Since 2 units of P2 and of P1 will be required to manufacture the FP the
quantity of their respective MOs should be at 2.
Cause of the issue:
Confirming the MO for FP will call the trigger_scheduler() on its raw
stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2
and P3. Since these ones are positive, procurement will be run for both
of these leading to the creation of 2 new MO's via the manufacture
route. The post process of the scheduler is then run
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and
confirm these, triggering the above process once more but now for the
MO's of P3 and P2 rather than FP: we start by computing the qty to order
for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to
compute this quantity, we look at the forecast of these quantities and
this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2
stock moves taking this product (one to manufacture FP and one to
manufacture P3) and one stock move bringing one unit of this product
(the one coming from the MO of P2 we are currently trying to confirm)
- `orderpoint._quantity_in_progress()` has a value of 1 due to the MO
of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at
0. This is a mistake since the incoming stock move for P2 is counted
twice in the forecast qty: once in each term. As a result no new
procurement will be generated for P2 hence the issue.
FIX:
Since this `_quantity_in_progress()` seems to have been introduced to
improve purchase flows rather than to interact with manufacturing flows:
https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for
the forecast qty to be correctly computed. This requires to ignore the
contribution of each mo triggering the scheduler and those that already
triggered the scheduler since the confirmation of the MO of FP.
Notes: The test sets a little more complex MO overview than the
above use case to be sure to catch corner cases situations.
opw-3689920
closesodoo/odoo#158217
X-original-commit: 4c0b9ef2ad75d3f831fce0abaa62a1d660ba5ca6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue: Currently if we have taxes for our Purchase no matter if we set
the tax to inactive or we archive it, we will have access to it on the
purchase_order_line.
Steps to reproduce:
- Install Purchase
- Create a new Tax and set it to inactive.
- Now create a new RfQ and in the lines add any product.
- Try to change the tax for this product.
Solution: since we need this weird behavior for the cases where the tax
was applied to a RfQ and afterwards this tax was archived for example,
we should implement the needed domain to the view so we cannot access
to apply it anymore after inactive but it will still be visible where it
was applied beforehand.
opw-3776871
closesodoo/odoo#158077
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
**Current behavior:**
Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1
then creating an invoice with this tax tied to a product will
cause a traceback when a user tries to confirm the invoice.
**Expected behavior:**
The invoice will post as any other might.
**Steps to reproduce:**
1. Create a NL company with l10n_nl_edi accounting
2. Create a tax with the following field values:
*tax computation: fixed*
*affect base of subsequent taxes: True*
*base affected by previous taxes: True*
3. In the customer invoices journal for the created company,
go to the 'Advanced Settings' notebook tab and enable the
NLCIUS and Peppol options under 'Electronic Invoicing'
4. Create a new invoice with some product and attach the newly
created tax to it, then try to confirm the invoice to see
the traceback
**Cause of the issue:**
The edi format tags invoke different instances of the
get_invoice_line_allowance_vals_list() method. This method
returns a dict list where the dicts only sometimes contain the
key 'allowance_charge_reason_code'. A subsequent expression
expects this key in the dict which can cause a KeyError.
**Fix:**
Check instead for a 'charge_indicator' key, which is present in
both the ubl_bis3 and nlcius_1 val dicts, allowing the correct
total to be summed and reflected in the EDI document output.
opw-3680527
closesodoo/odoo#157495
X-original-commit: 06a3027ca9f421ccc0081e2c8a5ff538175ef334
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Create a leave spanning multiple days;
2. create a public holiday that falls inside that leave;
3. check leave in list view & form view.
Issue
-----
The leave's duration no longer matches between the two views. In form
view, the duration was updated, in list view, it remained unchanged.
Cause
-----
There's nothing to trigger a recomputation of duration_display when
adding/removing leaves.
Solution
--------
The `number_of_days` field is kept up to date by the usage of
`add_to_compute` when modifying leaves. The same can be done for the
`duration_display` field.
opw-3642500
closesodoo/odoo#158296
X-original-commit: 1327b8014df79a488b1f7c1b909944ac8faff426
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Issue:
------
The `partner_autocomplete` module is an automatically installed module.
This module is not included in the dependencies
and can therefore be uninstalled.
If `partner_autocomplete` is uninstalled and we go to a shared project
with a portal user for example, we get an internal server error,
as we don't have access to the `partner_autocomplete` files.
Solution:
---------
Remove the `partner_autocomplete` files from the manifest file
of the `project` module.
Note:
If the widget is not found (in the very rare case of uninstalling
the `partner_autocomplete` module), we will use the
default widget (and create a log).
opw-3774575
closesodoo/odoo#157965
X-original-commit: 65331aee3b7c74752aed23e136f08ff1fb5d282d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
yosa-odoo