When a user try to import (to edit) some account.tax, some verification are done on pos.order.line.
The search is done in sudo but the read is executed with the current logged user.
So pos.order.line from others companies are check with a user who don't have access to these companies.
And the AccessError exception is triggered.
This PR aims to fix the permission issue by adding a sudo() for the read on pos.order.line
closesodoo/odoo#149288
X-original-commit: 1c22f6bd36ffcade3d84d0f76bbb3b9d1dc8c4c1
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, deleting recurrent events from Odoo in list view mode was allowed with the synchronization active, which could trigger to spamming emails on Microsoft side. Additionaly, deleting events with the synchronization off was also deleting events on Microsoft, which should not happen.
After this commit, the deletion of recurrent events is not allowed anymore when the synchronization is active by triggering an UserError message. Also, when the synchronization is off, deleting events in Odoo don't also delete events on Microsoft side.
closesodoo/odoo#149278
Task-id: 3563501
X-original-commit: a932aee25b2ae5f6a3c0e50154c5db6ba6ea06bf
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
To reproduce:
- Install POS with demo data
- Install Indian localization(l10n_in)
- Open POS terminal
- Click on the load demo data
- Traceback thrown
Fix:
The issue occurs when the demo data executes the closing of the sessions.
The l10n_in _post method checks for a company state that is not yet set
at that point. It is important to note that this issue only arises
when loading demo data on a DB that doesn't contain demo data. The solution
is to extract the part of the method that executes the demo data linked to
the main config and to override it to not perform that part in the l10n_in_pos.
closesodoo/odoo#149011
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Current behavior:
When you create a sale order with an analytic account, and settle it in
the POS, the analytic account is not set on the POS order invoice lines.
Steps to reproduce:
- Create a sale order with an analytic account (in other info tab)
- Confirm the sale order
- Go to the POS and settle the order
- Pay and invoice the order
- Go to the invoice and check the analytic account on the invoice lines
Note:
I based my fix on what was already done in the sale_order creation to
set the analytic distribution correctly on the invoice lines.
opw-3635140
closesodoo/odoo#147737
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The unit tests introduced in 4820be3c only work if pdfminer is installed.
As it's an optional dependency, it may not be installed in some environments.
This commit skips the tests if pdfminer is not installed.
See also: 6fa4dbf2closesodoo/odoo#147720
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit adds a test on the following flow:
A subcontracted product has its component having the three route
- ressuply on order
- buy
- MTO
Receiving the subcontracted product will create a delivery for the
component to the subcontractor, then a purchase order to buy it.
Confirming this very PO should create a receipt stock move linked to
this delivery.
closesodoo/odoo#147344
X-original-commit: 0044fd8bb6966011bd3943bff0bd58bcd111338f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Method _is_purchase_return had a complex check intended to detect
subcontract return move. This Check would incorrectly pass for
subcontract move when the destination location (input) does not belong
to the customer warehouse.
To fix this issue, we can check the field StockMove.is_subcontract,
however this field is only available if mrp_subcontracting is installed.
Furthermore, the check itself make no sens in purchase_stock if the
module mrp_subcontracting is not install Hence, we can move this check
to mrp_subcontracting_purchase.
With Purchase & Mrp Subcontracting installed:
- Create Component C, consumable
- Create Product P, storable, Set Vendor V under Purchase Tab
- Create BOM for P, subcontracted with Vendor V, and C as component
- In the Warehouse, set 2 steps reception
- Set Input parent location to 'Physical Location'
- Create PO to vendor V, product P, confirm, receive Product
=> Received Qty for P in PO show 0
OPW-3216011
X-original-commit: bf666d33af4ac32563e159cb6e79483d6f37b3d6
Part-of: odoo/odoo#147344
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to Reproduce
===================
1. Open any course
2. Go to the review tab
3. Tap on the comment button.
-> Currently the avatar image is a bit messy
Technical Reason
=================
This issue occurred after the portal redesign
https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8
After this commit
==================
The Avatar image is well-ordered.
Task-3625896
closesodoo/odoo#146092
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`replied_ratio` shouldn't be tested against bounced_ratio, neither
should be `opened_ratio` against `clicks_ratio`.
`_prepare_statistics_email_values` function returns list, whose last
two values are: `clicks_ratio` and `bounced_ratio` instead of
`opened_ratio` and `replied_ratio`. Also checking `replied_ratio` and
`opened_ratio` doesn't make sense, when testing sms.
task-3485424
closesodoo/odoo#149267
X-original-commit: a2bb6dea6d81a777c7aed73c8b7a38e015408676
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The kanban's create button ("New") is usually displayed in the
ControlPanel. But in the select/create dialog (like many2one dialog),
the create button is moved to the footer.
On small screen, the Many2X fields' selection view switches from a list
view to a kanban one but a different condition was used to display (or
not) the create button in the ControlPanel, which explains why the
ControlPanel's create button appears only on small screen (and not in
the same dialog open on desktop-like screen size).
This commit fixes it by reviewing the condition applied in both the list
and kanban views and normalizing them to be based on the (existing)
`showButtons` prop that controls the additional buttons added to the
ControlPanel.
Steps to reproduce (with a smartphone like screen size):
- open Contacts app
- open a contact
- open the company's selection
=> two "New" buttons are displayed (top and bottom)
opw-3431221
closesodoo/odoo#149329
X-original-commit: c21c600189b36b7b4b352f8017467c8ef7d07c87
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Peppol and Italian edi both uses a proxy user. We should only use Italian
proxy users when checking demo mode otherwise Peppol production proxy users
can interfere and trigger an error like 'Company already have prod connection'.
Also we don't want to delete demo Peppol connections.
opw-3675908
closesodoo/odoo#149276
X-original-commit: 078543cfe34427fe96932536bc283fcdf2ce2251
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
Before this commit:
If the username and password are wrong, then it only displays the error '108'.
After this commit:
If the username and password are wrong, then it displays the error.
'[108] Invalid login credentials.'
task - 3304862
closesodoo/odoo#149323
X-original-commit: a27421e0aab072a7c33b748f2d6162d1b2ea060f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Zeel Patel (zepa) <zepa@odoo.com>
...for orders made through Sales with loyalty programs that uses websites
Problem: For loyalty & gift card programs that has sales and website enabled along with a specified website,
the loyalty points will not accrue and gift card codes will generates for products if the SO was created with the Sales app.
Solution: The SO ordered through the website should filter based on the website_id. SOs created through Sales will not have a website_id, thus, no need to add an extra filter for website_id.
Gift card codes will generate and loyalty points will accrue for orders made through Sales even if the program has a website specified.
Steps to Reproduce on Runbot 16:
Create a new product of the type consumable
Go to Sales > Products > Gift cards & eWallet and click on NEW
For the Gift Card Products field add the previously created product
For the website field specify a specific website (e.g. My Website)
Create a new sale order for the originally created product
Confirm the sale order
Click on the Customer Preview smart button
You won’t see a gift card code anywhere when it should have been generated & Loyalty points are not accrued
opw-3550278
opw-3587226
closesodoo/odoo#149320
X-original-commit: eed913463ea4824586373cae608d7cfcb2ff20fc
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>
Steps:
- Update a module category to reference itself as parent
OR
- Update multiple module categories to create a circular dependency (A -> B -> A)
Actual result:
- Upgrade a module is impossible
- Un/Install a module is impossible
- Infinite loop: https://github.com/odoo/odoo/blob/15.0/odoo/addons/base/models/ir_module.py#L900
Expected result:
- Circular dependencies not possible
- Module can be upgrade and un/install
opw-3490162
closesodoo/odoo#149284
X-original-commit: 6932714200d158a21bf10b90b2f71fa5cae0b13f
Signed-off-by: Raphael Collet <rco@odoo.com>
Create an Invoice with 2 lines of product
Save
Delete one
Change currency
Save
Traceback will occur becasue of a ValueError
```
for command, line_id, line_vals in vals['invoice_line_ids']
ValueError: not enough values to unpack (expected 3, got 2)
```
opw-3672799
closesodoo/odoo#149261
Signed-off-by: William André (wan) <wan@odoo.com>
Problem: The description of a down payment SOL does not recompute for a locked SO when an invoice is confirmed.
Solution: Trigger the compute before it gets skipped due to the SO being locked.
Purpose: The down payment line should include its reference to the invoice name despite the SO being locked or not.
Steps to Reproduce on Runbot:
1. Install Sales
2. Enable "Lock Confirmed Sales" in Settings > Sale
3. Create a sales order and confirm
4. Create an invoice with down payment and confirm
5. Refer back to the sales order and the down payment line's description does not contain the invoice name
opw-3612298
closesodoo/odoo#149188
X-original-commit: 7393c7a8f203cbe1a946b3123719ff7e24dd0772
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>
A model can specify a preferred company (cid) when redirecting someone from a mail
link.
Before this commit, this cid was taken into account when redirecting only if the
user is logged in.
With this commit, even if the user is not logged in, the redirect link will take
that preferred cid into account.
opw-3613144
closesodoo/odoo#149254
X-original-commit: e70a27d820d94dba7e8c45865ddc5fbc46f9f26f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
Before this commit user was able to archive the language used by superuser
Odoobot by activating different language. Because of which whenever odoobot was
in action then the user faced error.
Steps to produce:
- Install `contacts`.
- Settings > Translations > Languages > Choose a language eg: English (UK).
- Activate that language and switch to it.
- In `contacts` change the language of each contact in the contacts to the
newly selected language.
- Settings > Translations > Languages > Choose English (US) and archive it.
- Settings > User & Companies > User, Apply the filter of Inactive Users.
After this commit user would not be able to archive the language used by
superuser or the language in which there db was installed.
Task-2896526
closesodoo/odoo#149215
X-original-commit: 681fc0a04c7ca625c7120ff2f7b537b75398b23d
Related: odoo/enterprise#54209
Signed-off-by: Raphael Collet <rco@odoo.com>
Issue:
- The course filtering feature was consistently providing incorrect
results, showing courses that were not related to the selected tags.
This issue did not appear when logged in as an admin user.
Steps to reproduce:
- Install the eLearning app.
- Navigate to the 'Courses' section on the website.
- Click on a tag to filter the displayed courses.
- Select additional tags to further filter the courses.
- Observe that the results may not correspond to the selected tags.
Solution:
- This inconsistency was caused by the t-cache directive in the template,
which cached parts of the page and didn't always reflect the latest
user interactions, like changing the selected tags.
- Modify the t-cache directive so that it caches the content only when
there are no search tags
opw-3636565
closesodoo/odoo#149197
X-original-commit: 3e0e3b2ea89639f1521335c36b11356e7b31ba4b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Purpose
=======
When a database is miss-configured, we have no other choices to
potentially spoof the FROM. We decided that a better heuristic would
be to use the notification email instead of the user email.
Task-3645895
closesodoo/odoo#149189
X-original-commit: eae9214ade8487ac326fc83abe67af53d861e00a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reduce spacing in product document form and align content in product document kanban details.
task-3512072
closesodoo/odoo#140901
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since [1], an error is raised when no app is detected on the clickbot.
The issue with this is that it's possible for a user to no have access
to any app. This occurs when we test single apps (web for instance) with
demo user.
The aim of the error is to detect if we are stuck on a tablet mode page.
Now, we change the test on the ensureHomeMenu function, to don't have
false positives, and detect correctly if we are stuck on a tablet mode
page.
Fixes runbot issue 52675
opw-3649047
[1] : 8f365824c9dddacf1b3a40688a30c8498df3d5d4
closesodoo/odoo#149214
X-original-commit: 10475a96401b02b95e92cc6c9eaa909aeb7de1d1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Inserting a cumulated graph view inside spreadsheet
(e.g. cumulated subscription MRR breakdown),
- apply a global filter to filter, let's say on the current
month
=> the first data point does not include data from before
the current month (the accumulation starts at 0, even though
there is data before)
You can also check the MRR evolution subscription dashboard,
"MRR over time" chart.
Note: with this fix, we assume all "cumulated" charts are also
"cumulated_start". Which is true in practice (only one cumulated
graph view in the entire codebase)
closesodoo/odoo#149084
Task: 3680601
Related: odoo/enterprise#54146
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Currently, if account_peppol module is installed on a non-verified database,
it is not possible to register on `l10n_it_edi`, even on the test server.
That happens because we do not limit the demo mode to peppol.
This commit adds an additional check for the proxy_type when handling demo.
We wrap `make_request` in the decorator because it's used in many places in account_peppol,
so the condition has to be added inside the decorator.
closesodoo/odoo#149016
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Label of guest name on public discuss welcome page
was gramatically incorrect. It should be "Logged in as"
rather than "Logged as".
Also took the opportunity to properly translate the label.
closesodoo/odoo#149187
X-original-commit: 9463c787e7804e5c2c525b9ecc096ee067f0dd3d
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Ngrok will be officially ending support for all ngrok agent versions 3.1
and older starting on January 15th, 2024.
So with this commit we install the latest version of ngrok 3.5.0
closesodoo/odoo#149178
X-original-commit: 7ccc58415ebab06f7b45eafb271f11605acd95a8
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Commit [1] replaced all uses of env._t by calling the _t function
directly, and removed _t from the env. This commit adapts a
forgotten occurrence.
c07181b20b
opw 3664779
closesodoo/odoo#149176
Related: odoo/enterprise#54195
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Currently, the price difference amls are currently using today's date
(so the date the bill is confirmed) for the exchange rate.
It is weird, as the balance of those price difference amls then depends
on the confirmation date of the bill.
It is also weird, as they may also then use a different exchange rate
than the other amls (that are using the bill date exchange rate).
The fix is to use the bill date exchange rate.
opw-3596209
closesodoo/odoo#149159
X-original-commit: 5bcc8850331b7f211f9d670b2af95ccff1ff5914
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
The user associated to an employee doesn't need to be in the same
company of the employee. When this happens, we could get a multi company
issue when trying to _only_ display the employee form.
One way this issue is triggered is when the partner of the associated
user is marked as partner_share=True. We may get an access error due to
the rule `base.res_partner_rule`.
Steps to reproduce:
1. Install HR module
2. Create an extra company with a user (U) on it. Ensure the partner of
U is also set as belonging to this second company.
3. Create an employee in the first company with associated user U.
4. Archive U (this makes the partner of U get partner_share=True)
5. Try to access the employee form from the first company.
We get an error:
```
Due to security restrictions, you are not allowed to access 'User' (res.users) records.
Records: U (id=11, company=COMP2)
User: Mitchell Admin (id=2)
This restriction is due to the following rules:
- user rule
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
Implicitly accessed through 'User' (res.users).
```
Since we allow hr.employee records to keep the associated archived user,
to avoid this issue (potentially triggered differently) we opt to
compute the avatar placeholder as sudo.
The issue has been observed in multiple upgrade requests.
closesodoo/odoo#149171
X-original-commit: 5136e86b4d47fae1a70cba0809906cfc625fd1de
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
To reproduce
============
- Website > Shipping methods > Pick-up in store
- Add a description displayed on the eCommerce
- add at least 3 or 4 lines with "enter" in between the lines.
- from the shop select Pick-up in store, the payment button will be locked
Problem
=======
- The method `_disablePayButtonNoPickupPoint` checks if there are pickup points
in a shipping method based on the count of children in the selected method
- The description will be counted as child which breaks the checking
Solution
========
check the existence of `.o_list_pickup_locations` instead
opw-3628025
closesodoo/odoo#149163
X-original-commit: cfaa0d47de2b4931f23994061ec489ae5705f181
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this commit:
===================
If by-product is updated in mo after confirm then the initial by-product is considered and the
new one is ignored in stock_move_line(Product moves).
After this commit:
==================
If by-product is updated in mo then the initial by-product will updated with
new one in stock_move_line(Product moves).
closesodoo/odoo#149074
Task: 3534703
X-original-commit: 8908db1271d369aa05ab77ffde9f51fe9c86cf6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue:
- when attempting to download the Picking Operations report for a
product with packaging, the report generation fails with an error.
Steps to Reproduce:
- Configure a product to include packaging details.
- Create a new quotation with the packaged product, and confirm it.
- Proceed to validate the delivery.
- In actions click on 'Print' > 'Picking Operations'.
- Notice the error.
Solution:
- Update the field product_packaging_quantity to the correct field name
product_packaging_qty.
OPW-3643483
closesodoo/odoo#147692
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The first search request for a VAT number will always fail,
because we validate the VAT based on previous requests of the VAT
before we return the company information to avoid returning the wrong company
If no validated VAT is found and vies vat found the company,
we return the information provided by vies vat
task-3548046
closesodoo/odoo#148972
X-original-commit: a591e9c061374bfaf84d41a94246cff83ab1899c
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Lina Eweis (liew) <liew@odoo.com>
Issue Description:
The partner() function previously inferred the country using GeoIP
when no specific country (nor "all_countries") was specified.
However, if there were no partners from the inferred country,
the render function would lead to a broken screen.
Resolution:
Implemented a fallback mechanism to treat the situation
as if no country was specified. This ensures that all partners are displayed
in such cases, preventing the occurrence of a broken screen.
[Reproducing bug]
- odoo 16.4 with: website, contacts, crm_enterprise_partner_assign
- Simulate GeoIP on the backend, so it points to some COUNTRY_A:
- this can be achived by adding `country= country_obj.search([('name', 'ilike', 'mex')])`
[below this line](https://github.com/odoo/odoo/blob/57d43aca2b07d3469a937890b7d5e5c4f29fe250/addons/website_crm_partner_assign/controllers/main.py#L237)
- note: it doesn't matter which country you set it to, AS LONG AS COUNTRY_A != COUNTRY_B
- in CRM/Contacts:
- create partner (set Partner Level and country to COUNTRY_B of the record )
- Publish partner by "Go to website" -> Published
- go to url: ODOO_WEBSITE/partners
- BUG: No Partners are displayed
opw-3598110
closesodoo/odoo#148822
X-original-commit: cfca987efe83e6a6ba27779246a2d5da6b86dc7f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Steps:
1. Install the Accounting module.
2. Enable cash rounding for Customer Invoices in the settings.
3. Activate Developer mode.
4. Navigate to Accounting > Configuration > Management > Cash Rounding.
5. Create a Cash Rounding rule with the following settings:
a. Rounding Precision = 1
b. Rounding Method = UP
c. Rounding Strategy = Add a rounding line.
6. Create a bill and apply the rounding rule. Add invoice lines with products
priced at $99.5 and a tax rate of 15%.
7. Confirm the invoice.
8. Access the cash rounding settings and change the Rounding Method to Down.
9. Open the bill, navigate to the "Other Info" page, and select the "To Check"
option.
This will result in a UserError: "You cannot modify the taxes related to a
posted journal item, you should reset the journal entry to draft to do so."
Reason:
If there is any change in the rounding method after the journal entry is
confirmed, the compute method of tax_totals is triggered when some field of that
record is modified. This may lead to the creation of another journal item or
changes to existing ones based on the new rounding configuration. However,
performing this on a confirmed entry is restricted so it will raise UserError.
Solution:
Don't compute rounding according to the amount_total after its conformation.
Instead, count it using journal items for type-rounding
Task - 3468308
closesodoo/odoo#149118
X-original-commit: 612d044b19072d549ba8b12eb3a9a7583adad174
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Install Accounting and l10n_sa_edi
- Connect with a non-admin user (e.g. Marc Demo)
- Switch to a SA company
- Create an invoice
- Click on "SEND & PRINT"
=> A traceback is raised when trying to access the attachment linked to
the ZATCA document.
Cause:
Since this commit https://github.com/odoo/odoo/commit/44a4cdb3944a4b722dcfbca5e2947a4372b8501d
the attachment of an EDI document is restricted to users with
"Administration: Settings" rights.
opw-3663305
closesodoo/odoo#149055
X-original-commit: 2fa9626f45b8c0c890d0771d731c4a13c5a7a9d1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The ListRenderer disables the checkbox of all lines corresponding to a
record which cannot be selected. Unfortunately, because
`canSelectRecord` is a getter, it is invoked once per line, and this
getter in turns invokes the `editedRecord` getter which scans all record
to find which record is selected. This operation is O(n²), so it's very
slow when there are a lot of records.
This commit fixes that by computing the value once per render.
Time to render the list view of views (technical > User Interface >
views) with 600 records visible:
- before: ~1800ms
- after: ~250ms
closesodoo/odoo#149051
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit when the user creates a task with a subtask and
save the form view and then go to the form view of the subtask and
set as project the same than the one set on the parent task, he cannot
save the form view. The reason is because the framework JS considers
there is nothing to save since in fact , the project set is the same
than the parent by default, it is just not displayed in the interface
thanks to the value of `display_in_project` field. The reason is
to be able to let the user choose if he wants to see the subtask in
the main views (list/kanban) of tasks linked to the project or just
below the parent task.
This commit fixes the issue by forcing to update the `display_in_project`
field even if it is not in the active fields since it is invisible
in the interface and only the widget set on the project field will
read and update it.
Steps to reproduce:
==================
- Install Project app
- Go to the project app
- Create project A
- Create a task inside that Project A
- Go to the form view of that task
- Create a subtask
- Save the form view
- Go to the form view of the subtask
- Set the project A as project for that subtask
- Save the form view
Current Behavior:
================
The form view cannot be saved because the framework JS considered
there is in fact, nothing to save since `display_in_project` is
not in the active fields and there is no force_save="1" set on the
field in the view definition.
Expected behavior:
=================
The form view should be saved.
closesodoo/odoo#149035
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
-------------------
- install the "hr" module;
- remove access rights for "Employees";
- change language on the user profile.
Issue:
------
There's an Access Error because we can't read the `private_street` field
on the employee that corresponds to the user.
Cause:
------
The new version of onchange fetches the record values on the server side,
unlike the old version which used the values in the view.
In the old version, as we were using view values, this didn't cause any problems,
as the values came from a read that which took into account `SELF_READABLE_FIELDS`.
Note:
We do not have access to the value of the `private_street` field because it is a
related field with the attribute `related_sudo=False` and we do not have
access rights for the `hr.employee` model.
Solution:
---------
Use the cache and place the values of the fields in `SELF_READABLE_FIELDS` in it
before performing the onchange logic.
opw-3664929
closesodoo/odoo#148997
Signed-off-by: Raphael Collet <rco@odoo.com>
When the server-side form view reads its record, the call to web_read()
leaves data in cache, which may prevent some access error to be
triggered in the first call to onchange(). In order to avoid that,
simply clean up the environment like after the other method calls.
Part-of: odoo/odoo#148997
Previously, product attributes were not displaying correctly due to
image retrieval from "product.attribute.value" conflicting with
searches based on "product.template.attribute.value" IDs. This commit
resolves the issue by ensuring the correct image display.
opw-3666883
closesodoo/odoo#148913
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Prior to this commit, the date search was hardcoded to
"yyyy-MM-dd HH:mm a", inconsistent with the system's date format
display. This commit adjusts the date search to align with the system
date format.
opw-3677157
closesodoo/odoo#148827
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Current behavior:
If you use a non cash payment method, with "identify customer" option
and register a payment difference at the closing of the session. The
difference is not taken into account in the session report.
Steps to reproduce:
- Activate "identify customer" option on the bank payment method
- Open a session
- Add a product to the order
- Pay the order with the bank payment method
- Close the session with a payment difference
- Print the session report
- Open the report, at the bottom you should see the payment difference
but it is not the case
opw-3597291
closesodoo/odoo#148753
X-original-commit: 30ba7fd9eb3d1910431cbf543e2ca691f0fdcfc0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
François Honoré