commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca
Issue:
======
valuation unit cost is wrong when we do backorder with real time unit
price computation
Steps to reproduce the issue:
=============================
- Create a kit with 2 components with product quntity to produce = 3
- Put qty = 2 for the first component and qty = 1 for the second component
- Assign product category to the kit product and the components as fifo
one with automatec price computation
- Create a purchase order with 30 quantity of the kit and price unit =
90
- confirm order and go to receipt
- Confirm 4 qty for the first component and 2 qty for the second.
- Create backorder
- Go to the confirmed receipt and go to valuation
- You will see that the total sum corresponds to the price of all the
products and not only the confirmed ones.
Solution:
=========
We need to use the bom quantities and not the order line to get the
unit_cost of each component.
opw-3790132
closesodoo/odoo#158788
X-original-commit: a72232694f68a810986e5c1c24fd0394d058af41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
- Create PO
- Confirm, delivery and create bill
- Confirm and create reverse move via "Add credit note" (Full Refund)
- Open portal view of the PO
Issue: The credit note payment status display `Waiting Payment` badge
instead of `Paid`
opw-3806514
closesodoo/odoo#158556
X-original-commit: 66d08a484dae64f559a78ccee18b4a79f9e4e70e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key).
Previously, the field `image_1920` was used which has two issues:
1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used.
2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so:
a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157
b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550
So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead.
Memory benchmarks for allocations by `_get_self_order_data`:
Done on customer DB with 1340 product.products, with a total of 776 images between them.
Before commit: 1638.4 MiB + server memory limit reached
After commit: 29.7 MiB total
Total improvement of 55x less memory usage
closesodoo/odoo#157900
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
To reproduce issue:
.create a new picking of any operation type
.save the picking (so that a name is formed)
.edit the picking and change the operation type to another type
.save manually
Expected result:
new name with matching prefix to the new operation type
Actual result:
previous name with prefix from previous operation type is still
there. This is an issue because then the name doesn't match and
this can be confusing to users
When a user create a new picking of any operation type and save the
picking, the name is formed based on your type. If the status of
picking is draft, and he needs change the picking type, the name of
picking is not changed, so, this PR solves this error. Now, when
change the picking type and save it manually, the name of picking
will be regenerated with the correct specification. Should be receipts,
workorders or delivery.
task-3703643
closesodoo/odoo#153147
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, it happens that the taxes display on the pdf were wrap,
specially when the description in the pdf were too long. This commit will add a
text-nowrap on the taxes when the len of the taxes is shorter than 10 characters
closesodoo/odoo#158774
Task: 3754824
X-original-commit: 95d0bd1794418ac8bdb4464c54304d3dcd0cb523
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- Create pricelist with an end date in the past for a stored product
- Click on manual replenishement
- The created PO will have a price of 0
Bug:
if no valid pricelist is found unit price is set to 0
product standard price is a better fallback
opw-3692985
closesodoo/odoo#158650
X-original-commit: ed106e70f908deda819007fc68feaa44074c0472
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
If phonenumbers library is not installed, we should display a
relevant error message, instead of the generic invalid phone number
error message.
closesodoo/odoo#154926closesodoo/odoo#158546
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Now that we check whether a participant exists on Peppol network first when they register,
we should also mock that request. Currently, since that request is not mocked,
all peppol tests are skipped.
Part-of: odoo/odoo#158546
If the participant is not active on the IAP server, the server sends back
a Participant not ready error in response without raising an error.
On the client side a user sees a traceback, because we're trying to retrieve
a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid'].
That's because we treat that error in the try block and then proceed
to the else block because technically there was no exception.
This commit moves that error handling to `else` block so that such invoices get the proper error messages.
Part-of: odoo/odoo#158546
Before this commit:
In POS online payment the usually the user is either the
logged in user/public user which ends up raising error
`The phone number is invalid` even when the customer is selected
After this commit:
Razorpay doesn't raise the error instead now we don't create
customer when it is not a tokenize request
task-3786679
closesodoo/odoo#157533
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Those are optional, commit [1] mimicked the python code in JS but with a
mistake: "required" instead of "optional".
Steps to reproduce:
- Enable cookies setting on website
- Drag & drop a snippet
- Modify that snippet conditional visibility to "Utm Campaign: Sale"
- Visit in incognito /?utm_campaign=Sale, you don't see the snippet,
which is good
- Now click on "Only Essentials" in the cookies banner
- The snippet will be shown, because when accepting the essentials
cookies, the utm ones were set, since they were marked as required.
[1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eecclosesodoo/odoo#158720
X-original-commit: 63b0606d728be949cc6cfcb0dbdf17114ec1c711
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Those master data would break the basic accounting pdf generation flow
as those are widely used and it is not expected from end users to delete
them.
Example of support ticket from that issue: 3790875
closesodoo/odoo#158637
Taskid: 3802440
X-original-commit: b1ecc922503ff3a9618e89afd13659e37eb3fbed
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets are issues when the end user deleted this product
category, leading to the impossibility to install another carrier
as this category is referenced by all the specific carriers products
Ticket example: 3789116
closesodoo/odoo#158626
Taskid: 3802440
X-original-commit: 9383b6f4a5ef0394588c522efcc92e6f37a245cb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
When you increase the height or width of cells in a table and subsequently
delete a row or column, the adjacent rows or columns experience an increase in
their height or width. This happens because the table preserves its overall
dimensions even after resizing individual cells.
After this commit:
Now, the table no longer preserves its height or width. When resizing the table,
the height or width of its rows or columns does not increase.
task-3636212
closesodoo/odoo#158256
X-original-commit: 9940bf3e153714022785b50cb423e52634c99202
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
- When adding tasks to a contact using Studio
and attempting to set a task's project to a
project linked to a Sales Order (SO),
we encounter the following error:
"TypeError: 'NewId' object is not iterable."
Steps To Reproduce (in 17.0):
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project
related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
Solution:
- The issue arises in the search domain of
_get_last_sol_of_customer , where the domain is
('order_partner_id', 'child_of',
self.partner_id.commercial_partner_id.id),
where the type of `self.partner_id.commercial_partner_id.id`
is NewId since the partner is being edited to add a task.
This action triggers the `parse` and `to_ids` methods with
a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids
property refer to the record's origin ids.to resolve this,
replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
closesodoo/odoo#157318
Signed-off-by: Raphael Collet <rco@odoo.com>
Imagine the following situation: an automated action A is triggered when
some stored computed field F has a certain value. When a record is
created and no value is given for field F, then the automated action A
may be run twice: once when evaluating A's domain forces the computation
of F, and once again because A's domain is satisfied.
The implementation already uses context flags to reflect which automated
actions have already been run, in order to avoid automated actions to be
run recursively. The fix consists in enabling those context flags to be
shared among the evaluation of the domain and processing of the
automated actions.
opw-3731182
closesodoo/odoo#157272
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Nasreddin Boulif (bon) <bon@odoo.com>
After the fw-port of the fix in [1], it seems some references had
changed, breaking the translations again. This commit fixes that.
[1] 9d2f7f312c5d699b937bd5546085fc151a149a8f
closesodoo/odoo#158664
X-original-commit: d28189565f035cf2f84f7cb01137cece2bb90662
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
is checked but not the display name of the product.
It is not necessary for the purpose of the change and adapting
the display name on the product is very common customization
for many companies.
X-original-commit: bbba3cd6e5affff53728d877b0d426eb6c88ff38
Part-of: odoo/odoo#158621
Incorporate Christihan Laurel (CLaurelB) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at
http://www.odoo.com/submit-prclosesodoo/odoo#158729
X-original-commit: f0a0d596ab716c96de38a5c0f837da2924338d7b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If the 'cancel next move' feature is enabled, canceling a SOL could
lead to unexpected picking creation
To reproduce the issue:
(Debug mode enabled)
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Outgoing shipments: 2 steps
3. Edit the delivery route:
- For each rule:
- Cancel next move: True
4. Confirm a SO with one product
5. Set the SOL quantity to 0
Error: A third picking is created, from customer to output location
Step 4, it creates two SM:
\- SM_SO: from Stock to Ouput
\- SM_OC: from Output to Customer
Step 5, thanks to the procurement process, we create a stock move:
\- SM_OC_neg, from Output to Customer with a negative qty.
While confirming this SM, and thanks to the same process, we then
create a second stock move :
\- SM_SO_neg, from Stock to Output, with a negative qty.
Both negative SM are linked. While confirming SM_SO_neg, we merge it
with SM_SO. Therefore:
\- Dest moves of SM_SO_neg are given to SM_SO
\- SM_SO_neg is deleted (fully absorbed by SM_SO)
\- SM_SO has now a zero demand, so we cancel it:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1024-L1025
However, because of step 3, we also cancel its dest moves:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1740-L1745
i.e., we cancel SM_OC *and* SM_OC_neg. This leads to an inconsistency:
Back to the confirmation of SM_SO_neg. As explained, this SM has
been canceled during the procurement process. Still, we keep
processing its confirmation (we overwrite its state, we assign it to a
picking, and so on). Hence the error.
In `_merge_moves`, when deleting a stock move, we first clean it
(for instance, we disable the cancel propagation):
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1018-L1020
We should do the same with SMs we are going to cancel. That way, we
fix the root cause of the issue: when cancelling SM_SO, we don't
cancel neither SM_OC neither SM_OC_neg, so we don't have any
inconsistency when going back to the confirmation of SM_SO_neg, and
everything will work correctly.
OPW-3753453
closesodoo/odoo#158663
X-original-commit: 7f385686b35b36561cfe9d2a320ff1699547efd2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
With a SA company setup
Open a jounrnal entry
Hit 'Reverse Entry' > Reverse
Error: "For Credit/Debit notes issued in Saudi Arabia, you need to
specify a Reason"
This occurs because with SA localization we need to provide a reason for
move reversal but by default the reason field is invisible for journal entries
opw-3789732
closesodoo/odoo#157996
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Steps to reproduce:
- Open an event and go to the Community page
- Try to customize it => traceback on clicking the 'Customize' tab.
Cause:
The `_getRpcData` function called by '_computeWidgetState' method does not exist
anymore since https://github.com/odoo/odoo/commit/03c5526
Fix:
This commit eliminates the call to the `_getRpcData` function and alters
the code of 'options.js' to get rpcData for the 'allow room creation' checkbox,
through an implementation similar to that of 'website menu'.
closesodoo/odoo#158684
Task: 3805901
X-original-commit: 1ea9c23eaaab15b6e29b73b9ec530fc9baec0726
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
Some taxes of skr03 and skr04 were not set for the appropriate tax group.
This was fixed, and each tax was set to its appropriate tax group.
Taxes should not be set with wrong tax groups.
task-3800915
closesodoo/odoo#158619
X-original-commit: 540f98de72c27659a6a9c938d2e75196e9b713c0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>
This issue is occurring when the user tries to add a VAT number
while creating a new contact
To reproduce this issue:
1) Install "contacts" and "partner_autocomplete"
2) Create a new contact from 'Contacts'
3) Give a valid VAT number e.g:- "SK2120312645"
4) Traceback occurs in the terminal
Error:- "IndexError: list index out of range"
https://github.com/odoo/odoo/blob/382b64c2f14073cfff1a8ef9290b5c7834d52188/addons/partner_autocomplete/models/res_partner.py#L143-L156
In some cases, the expected "zip_city" value is not at the last of the address list ,
which leads to a traceback.
After applying this commit will resolve this issue by searching "zip_city"
based on regex.
sentry-5058467547
closesodoo/odoo#158580
X-original-commit: 55c605f44d3a4f280946f1c1fec3f5e1534b4ef9
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Steps to reproduce:
- Install contacts and base_address_extended
- Install a module adding "res.city" records (e.g. l10n_co_edi)
- Go to Contacts and create a new one:
* Name: [any]
* Country: Colombia
* City (city_id): [any]
- Create a "child" contact of "Contact" type
- Save the contact
Issue:
"city_id" field of the child contact is False.
It is not possible to set the address of a contact-type contact manually.
Some address fields ('street', 'street2', 'zip', 'city', 'state_id', 'country_id')
are synchronized with the parent contact.
"city_id" is not and is not settable at all for contact-type contact.
It could be an issue for Colombian or Mexican localizations if a child contact is
used for an invoice as some data have to be retrieved from "city_id" field to generate
the electronic invoice.
Solution:
Add "city_id" in the list of address fields to sync.
opw-3747296
closesodoo/odoo#158686
X-original-commit: ec059dfd0a3f57754bd481f0a651b01c92b10dea
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Many banks (Itaú, Santander, Caixa) don't support Pix codes without a
reference. To fix set a dummy reference of "***" when none is
set (this is what Santander bank does when generating Pix codes
without a reference). Again thanks to INGO for testing.
opw-3818534
closesodoo/odoo#158713
Signed-off-by: Josse Colpaert <jco@odoo.com>
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>
Mahdi Cheikh Rouhou (macr)