Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner
function first looked for a partner with company_id = env.company.id. If
a parter wasn't found, a global search without constraining `company_id`
was made.
Thus, a search in a database with 2 partners with the same VAT (one has
a company_id, the other not) would return the partner linked to the
right company.
After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the
case. The search is done with `[('company_id', 'in',
[self.env.company.id, False])`, so 2 partners are found, and none are
returned.
We reintroduce that loop in this commit to fix that case.
closesodoo/odoo#163702
X-original-commit: ff71f130cf19732f803fe8c2fbf1fc08c41dbc35
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Current behavior:
When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able
This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe)
Steps to reproduce the error :
- Create an employee not related to a user
- Configure alias for expenses
- Try to send an email to the expense's alias and check at the logs
After this commit:
Employees without a related user will be able to create an expense from an email alias
opw-3892778
opw-3892701
opw-3893319
opw-3893591
closesodoo/odoo#163672
X-original-commit: 1dd67119c27d219eac2b726ef88cc4af3bed2814
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Otherwise we leave the constraints in the table. Common source of
upgrade issues.
closesodoo/odoo#163623
X-original-commit: 847a24e6f7f57c755cf6f42597b1ac75908f2c83
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Steps to reproduce the issue:
1. Create a purchase Tax and tick Include in Price in the Advanced Options
2. Create a Purchase Order with Analytic Distribution towards a Project in the Order Line
3. Set the purchase Tax created before as the tax of the Order Line
4. Confirm the Purchase Order
5. Make sure the Project is Billable, then go to the Project Updates
6. The profitability calculated the price with the included Tax
7. Create a Vendor Bill and set the same Tax and Analytic Distribution as the Purchase order
8. Confirm the Bill
9. Return to the Project Updates
10. The profitability doesn't calculate the included Tax
Explanation:
In `project.project._get_profitability_items`, we can find an inconsistency in the queries.
The query for `purchase.order.line` is looking for `price_unit`, which takes included taxes into account.
https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L125-L132
The query for `account.move.line` retrieves `price_subtotal`, which does not.
https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L171-L181
Suggested fix:
In `project.project._get_revenues_items_from_invoices`, the `account.move.line` query retrieves `price_subtotal` as well.
https://github.com/odoo/odoo/blob/8750b94c53c6ab58567873b0745fa6d9a18c97d0/addons/sale_project/models/project.py#L467-L474
With above information and input of PO (olma), taxes will not be calculated in `project.project._get_profitability_items`, therefore we will replace `price_unit` with `price_subtotal` in the `purchase.order.line` query.
opw-3781426
closesodoo/odoo#163567
X-original-commit: d4fa9ff7b1e2e8b5cd466d0f5433f99a1b407ac9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
Be sure to have the `sale_sms` module installed.
- Connect as Marc Demo. Note: Marc has the administrator access rights
in every service application including projects,...
- Go to the field service app create a new task and change its state to
`planned`.
> Access error: you are not allowed to access 'SMS Templates'
Expected behavior:
Since the newly created user has the rights to modify the state of the
task and since he does not try to access the content of any sms.template
he should not raise this access error.
Cause of the issue:
The stage `planned` is associated with an SMS template. As such, when a
task is moved to this stage, an sms will be sent using the template.
This action is done during the `write` override of the `project_sms`
module:
https://github.com/odoo/odoo/blob/5f1a3bdcaa63492cf169f6f5f3eb2e2281ad5ab5/addons/project_sms/models/project_task.py#L24-L32
However, this `_send_sms` method will need to 'read' the sms.template to
generate the sms:
https://github.com/odoo/odoo/blob/e6be732450d9ef662a48ba074e1ca1ad32e35c04/addons/sms/models/mail_thread.py#L191-L192
Since the user does not have the acess rights to 'read' this template
because of the `ir_rule_sms_template_so_sale_manager` access rule
defined in the `sale_sms` module, the access error will be raised.
Fix:
Since the `_send_sms` method will only read records in order to generate
the sms that will be send, we should bypass access rigths checks during
the call of this method.
Note: this was already the solution used for portal users.
opw-3789197
closesodoo/odoo#163525
X-original-commit: b5b63509a6bc4467cf84cd15ebdf3b4b0601aeb0
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Create a storable product C1:
- standard_price: $10
- Update the quantity to 2 units
- Create a storable product P1 with BoM:
- Component: 1 unit of C1
- Create a MO to produce 1 unit of P1:
- Confirm it
- Update the price of C1 to $20
- Go back to the MO and set the quantity consumed of C1 to 2
- Mark the MO as done
- Confirm the difference in consumption
Problem:
Another move is created with 1 unit of C1 consumed but is not merged
with the first move because the two moves were created with different
prices, making them incompatible for merging.
Solution:
There's no need to create the moves with `price_unit`.
OPW-3791816
closesodoo/odoo#163175
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
We are in the context of anglo-saxon accounting, when selling a product
having an automated valuation. The invoice linked to the `pos.order`
should have its stock output line reconciled with its counterpart in
the stock valuation journal. That is what happens if you create the
invoice directly from point of sale.
Currently, if you do not create the invoice, keep the session open and
then click the "Invoice" button on the pos order, the stock output line
will not be reconciled.
This happens because in `action_pos_order_invoice`, the picking is
created after the invoice. But the reconciliation happens when creating
the invoice. As it doesn't have its valuation counterpart yet (which is
created from the picking), it then do not reconcile with anything.
The fix here is to create the picking before.
opw-3702345
closesodoo/odoo#163157
X-original-commit: abf3f16ea6bb0278b2d44de281d69d3cfc8ac4cb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
See discussions on https://github.com/odoo/odoo/pull/85494/.
TLDR: webp image format needs to be supported, but we should avoid
going through the Pillow library as it is largely unsafe for that format.
jpg attachment are created in JS at upload time.
Wkhtmltopdf doesn't support webp, so, in reports, we should display one of those jpg copies.
This work is handled by `ir.qweb: _get_converted_image_data_uri` which is used as:
```xml
<img src="image_data_uri(some_b64value)" />
```
The mentioned PR did not however adapt the ir.qweb.field.image that, when passed the option `qweb_img_raw_data`
should return a base64 url such as `data:[mimetype],base64,[datas]`.
usage:
```xml
<span t-field="object.image_field" t-options-widget="'image'" t-options-qweb_img_raw_data="1" />
```
Hence, before this commit, there was a crash as we tried to pass that value to PIL.
After this commit, there is no crash, and the image displays correctly as JPG in the PDF
opw-3859423
closesodoo/odoo#163003
X-original-commit: 9056a4b1f28e820c0444f28367cc30abebd5ea30
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In Documents when dragging a workspace in the search panel
to resequence it there was no visual effect showing where
the workspace would drop. This was due to some css rules that
were replaced by a bootstrap class in the following
commit : 6f63e2349c
In our case, the `o_search_panel_category_value` node already
has a `py-1` bootstrap class, which overrides the value set
by the `py-0` class.
this commit restores the `padding-top: 0 !important;` and
`padding-bottom:0 !important;` rules to avoid conflict with
other py-X CSS rules (e.g.: py-1, py-2, ...)
Task-3877426
closesodoo/odoo#162948
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Currently, when we have an accrual plan where the accrued time is
allocated at the start of the accrual period and we set the allocation
start time in the past, the plan will be processed but already_accrued
will not be saved.
Example:
- We have an accrual plan that allocates 1 day per month at the start
of the accrual period. Milestone reached 0 days after allocation
start.
- We set the start date of the allocation to 2024-01-01, the current
date is 2024-03-15. The number of days are calculated to 3.00
(jan, feb, mar).
- We save the record, already_accrued is not saved (defaults to false)
- When the scheduled action runs (2024-04-01), it will allocate 2 days
instead of 1
This commit fixes this behavior by adding the already_accrued field to
the form view so that it is saved when the record is created.
opw-3851320
closesodoo/odoo#161508
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
- 303A Servicios profesionales prestados por sociedades residentes
- 312A COMPRAS AL PRODUCTOR: de bienes de origen bioacuático, forestal y los descritos el art.27.1 de LRTI
- 312C COMPRAS AL COMERCIALIZADOR: de bienes de origen bioacuático, forestal y los descritos el art.27.1 de LRTI
- 343C Recepción de botellas plásticas no retornables de PET
closesodoo/odoo#163593
X-original-commit: ed01d20579604e7b6ead4d4d0ad68b11f7fe8eb4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Install Contacts, Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Create a contact who is not in Saudi Arabia:
* Address: [Complete address in United Arab Emirates]
* VAT: [any]
- Create an invoice:
* Customer: [The created contact]
* Product: [any]
- Confirm the invoice
- Process by ZATCA
Issue:
The following warning is returned:
"The other Buyer ID (BT-46) must present in the tax invoice and associated
debit notes and credit notes (KSA-2, position 1 and 2 = 01), where the buyer
VAT registration number or buyer group VAT registration number (BT-48) is
not provided."
Cause:
"PartyIdentification" element is not set in the electronic invoice for customer
because he doesn't have "l10n_sa_additional_identification_number" field set.
This field is only available for contacts living in Saudi Arabia.
For contacts who don't live in Saudi Arabia, "PartyIdentification" should be
populate with their VAT number.
opw-3845645
closesodoo/odoo#163652
X-original-commit: 3500c5f5dc78ea88bb662bb08cb6c59482f502db
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Install Accounting
- Go to "Settings / Users & Companies / Companies"
- Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany)
- Switch to Branch Company
- Create a fiscal position
Issue:
It is not possible to select the taxes from the parent company in the
tax mapping.
opw-3850514
closesodoo/odoo#163552
X-original-commit: f1f561b720e040c7284d42a6d1ce840ff86e7237
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The goal of this commit is to forward port [the original commit] which
was introduced in 16.4 but, due to an error, has not been forward
ported.
Original commit message:
Since [1] when uploading images from URL the data is downloaded and then
hosted on the Odoo instance. As stated in its task (task-3129360) it
should not have been applied to document URLs.
Because of this, when hitting a CORS issue to fetch binary data, we try
to fetch the data through an `<img>` element by setting its `src` field
- which also fails when the data is not an image.
This commit makes the changes of [1] specific to image uploads and
restores the previous behavior for other files.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Double-click on the image.
- Go to the Documents tab.
- Click on "Add URL".
- Enter an example PDF URL.
E.g.: https://www.africau.edu/images/default/sample.pdf
- Click on "Add URL".
=> Fails because of a CORS issue.
[the original commit]: https://github.com/odoo/odoo/commit/238566d1dea29fd11353e7e6529d29843c4f658b
[1]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a
task-3493618
closesodoo/odoo#163576
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`extract_can_show_send_button` is a computed readonly field, providing a default value doesn't do anything.
By setting `is_in_extractable_state` to `False` by default, we can hide the ocr button.
no task, noticed while fixing a traceback in saas-17.1
closesodoo/odoo#163568
X-original-commit: d4b06d49624a1e3c5ecbb4d0c755a165cf213120
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
This commit adapts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and
7a78839ca6cf45ddec7adb59051da132e0ebceb4
The commits above try to split the origin moves during a split
(backorder). The issues was the split move lost its correct origin move
and the backorder move had all the origin moves linked to it.
HOW TO REPRODUCE:
- Create product FNS (storable)
- Create subcontracted BoM for FNS
- On Operation type 'Receipt', set Show Detailed Operations = True and
Pre-fill Detailed Operations = True
- Create PO for 10 units of FNS -> Confirm
- Go to Receipt > Detailed operation > Set quantity = 1 > Validate (with
backorder)
- Repeat step above on the created backorder
OR
- Create storable product FNS tracked by serial number
- Create subcontracting BoM, with strict consumption
- Create PO for 10 units of FNS -> Confirm
- Open detailed operation, add 2 lines with SN, confirm, Validate &
create backorder
- Redo the same step with backorder receipt
OPW-3838250 OPW-3812937
closesodoo/odoo#163553
X-original-commit: db78c0bdd4a50e094f8867b58b651e06a8822a8a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Currently, when the `invoice_date` of an invoice is updated (triggering
the recomputation of `date`) and if a system flush occurs before any
line's date is accessed, the invoice lines' dates do not get updated.
The following test illustrates this issue:
```py
move = self.init_invoice(
move_type='in_invoice',
partner=self.partner_a,
amounts=[1000.0],
)
move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()
for line in move.line_ids:
self.assertEqual(line.date, move.date) # will fail
```
Cause
-----
The `date` of a move is a computed field dependent on the move's
`invoice_date`. The `date` of a move line is a related field, pointing
to its parent move's `date` (note: related fields are computed fields).
During a flush, the system recomputes all fields that need to be. Here,
the system first processes 'account.move.date' and calls its computation
(`_compute_date`). However, the `_affect_tax_report()` call within
`_compute_date` triggers a recalculation of `account.move.line.date`,
but as this happens within `_compute_date`, the invoice lines' `date` is
recalculated using the old invoice `date`.
Fix
---
Force a recalculation of the invoice lines' dates whenever the invoice's
date is changed.
opw-3759472
opw-3875405
opw-3872006
opw-3884013
closesodoo/odoo#163530
X-original-commit: e9d955c5a52902cdac86c6285204c54876c68eac
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
When the report is updated and `groupby` is updated, we might need to
also update `user_groupby` if it was not compatible.
Followup/fix of 7d54c76aaee325449248fa698adb9e549c486ee
For instance upgrading from before to after
odoo/enterprise@d226977e19 was an issue.
closesodoo/odoo#163526
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce the problem:
1. Add a many2one field to lines of a model, example: sale.order.line
2. Add it to form view of the lines with a domain
3. Click on Search more... option
4. You will see results out of the scope of the domain
In the getDomain is passed an object that has only the key
fieldName but for knew in what view is the field placed
it needs to be provided the key viewType, this both are placed
on the class object this.recordParams builded at:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L129
If this key is not provided the viewType is beeing filled
with the element viewType, this element is the record opened placed
in the parent view, so by default if will be kanban or list. So
if the domain is filled just in the form view, the search panel
will get the domain [], so all the entries will be displayed and
they will be able to be selected.
If we see the next line:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L431
We will see that getContext is getting this.recordParams as
argument, for the same reason that the domain should have it.
With this changes the getDomain method is getting the viewType
to take the domain instead of the viewType of the lines displayed
on the parent view.
closesodoo/odoo#163513
X-original-commit: 1eef2e8711124df9cbe7373ef6056b51f1b2617c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Previously, when receiving a new email to create a job applicant for an
existing partner, the process would inadvertently erase the phone and
mobile numbers on the partner by using the inverse method.
With this commit, the behavior is adjusted so that phone numbers are only
written in the inverse method on the partner if there is a number present on
the applicant. This prevents the inadvertent removal of phone numbers on the
partner when creating new applicants for existing partners.
Additionally, this commit ensures that phone numbers from the partner are
computed on the applicant as if they were related non-stored fields. This
avoids the need for manual re-encoding of numbers later and prevents the
inverse method from being forced again.
Furthermore, to optimize the process, email changes are now only processed
using the inverse method if the normalized version of the email is different.
This prevents unnecessary method calls on the highly used res.partner model
when the email is updated, particularly for cases where the normalized version
remains the same.
Previously, changing the partner's email from `jke@odoo.com` to
`"JKE" jke@odoo.com` would resend all waiting sign requests because the
normalized versions of the email were distinct. While ideally, this check could
be performed within the sign request code itself, this optimization now helps
prevent unnecessary overrides across all modules simultaneously.
closesodoo/odoo#163495
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”.
- Update its quantity to 10.
- Create a delivery picking:
- Add the product “P1” with 10 units.
- Mark as to do.
- Scrap 1 quantity of “P1”.
- Try to validate the picking.
Problem:
A wizard asking to create a backorder is triggered. This occurs because
the move of the scrap is created, linked to the picking, and marked as
'done' (so, picked). Therefore, when validating the picking, we will
checks if all the moves are picked (Even if not picked, it will
work because we'll set them all to 'picked'). but as the first move is
not picked and the scrap one is picked, the backorder wizard is raised.
**opw-3821869**
closesodoo/odoo#163395
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In stock, you would print multiple times the same lot label.
In this scenario, the rendering method get multiple times the same res_id as parameter.
However, the code is loosing track of those duplicated ids before all
streams are indexed by res_id.
closesodoo/odoo#163362
X-original-commit: fb92e991bb98e5945c57c157754ff0eba306b924
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The COA should be visible, so existing db won't crash.
Indeed, it is used in the Selection field of the config settings.
As the field does not exist, the users get an error.
We instead don't let a user apply the Syscohada template to a
company that does not already have the COA.
opw-3893013
opw-3891587
opw-3891028
closesodoo/odoo#163350
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to Reproduce on Runbot:
- Install MRP
- Create a second warehouse
- Go to Warehouse -> Routes -> Manufacturing.
- Set the "Supplied Warehouse" to the first warehouse.
- In Inventory > Opertaions > Replenishment
- Create a new Replenishment with Manufacturing route
- click on Replenishment information (small "i" button)
- Expected singelton traceback error.
Fix:
get_lead_time in Manufacturing expects a single rule
using _get_rule to deteermine the correct rule as the
comment sugessted
opw-3838099
closesodoo/odoo#163318
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, if the product type is set to 'product' and recurring_invoice is
true, and the product has a bill of materials (BOM) with the type 'kit'
the picking was not created after the first invoice.
Producing steps:
- Create a subscription product with the type set to 'product'
- Create a BOM for that product with the BOM type set to 'kit'
- In the component, add any product with the type 'product'
- Create a sale order with the products that are created and generate an invoice
- Upon creating the next invoice for the subscription product,
the picking was not being generated.
With this commit, we are ensuring that the picking for subscription products
is now correctly created when generating an invoice.
task-3681597
closesodoo/odoo#163243
X-original-commit: ee15fc0c45f08c1fbef9d9062041ea8ff9bb0f59
Related: odoo/enterprise#61415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Prior to this commit, it was possible to duplicate a PoS order from
the backend.
opw-3839287
closesodoo/odoo#163018
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
This commit add the logging of hash string data. By printing the string
to hash, it becomes easier to investigate issues.
opw-3839287
Part-of: odoo/odoo#163018
Since the introduction of `user_id` field, it makes sense to allow
those users to update/read/delete templates they have been assigned to.
task-3748816
closesodoo/odoo#162400
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user.
Steps to reproduce:
-------------------
* Go to the **Time Off** app
* Select **Configuration** > **Time Off Type**
* Create a new time off type
* Approval: By Employee's Approver and Time Off Oficcer
* Requires allocation: Yes
* Employee Requests: Extra Days Requests Allowed
* Approval: Approved by Time Off Officer
* Notified Time off officer: Mitchell Admin
* Select **Management** > **Allocations**
* Create a new allocation
* Employees: Mitchell Admin
* Time off time: The one created previously
* Validate the allocation
* Select **Management** > **Time Off**
* create a new time off
* Employees: Any Employee A & Employee B
* Time off type:
> Observation: The new time off time is present in the name search while both employees don't have any allocation for it.
Why the fix:
------------
The name search searches for time off type with
```
['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]]
```
By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok
`has_valid_allocation` has a search method `_search_valid`
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138
`max_leaves` has a search method `_search_max_leaves`
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192
Both use the function `_get_contextual_employee` to make their search.
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388
When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin.
The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form.
opw-3816442
closesodoo/odoo#161713
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
When bin_size=True is in the context, a computed non-attachment binary
is incorrectly saved to the database. The row is actually updated with
the size of the binary instead of the value itself.
This commit fixes the problem by avoiding setting the cache with the
bin_size value as dirty.
Moreover, the binary size is computed with `pg_size_pretty` for
non-attachment binary fields. Also, method compute_value() calls
b64decode() on the value that was previously encoded in base64 by
_compute_datas(). But _compute_datas() is specific to attachments, and
is not used in this case. Thus b64decode() doesn't make sense.
These 3 bugs are now covered by testing web_save(), where cache
consistency is required. It was first reported for this method.
Closes#156673closesodoo/odoo#160708
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Renaud Thiry <reth@odoo.com>
Non-attachment binary fields need to be flushed before reading their
size, since the latter relies on the database's binary size function.
Part-of: odoo/odoo#160708
After writing or creating on a related Image field, its cache contains
the full-size image instead of the resized one (according to its
attributes max_width and max_height). Fix the cache with the resized
image at the end of the inverse method.
Part-of: odoo/odoo#160708
When invoking create() or write() with a binary field, the cache of the
field was incorrect if bin_size=True was in context. Force context with
bin_size=False when putting a binary value in cache. It is particularly
important to have coherent values in the cache for `web_save`.
Also, because an environment with bin_size=False won't return the same
context cache key as one with bin_size=None, it leads to have a cache
inconstistency when we write with bin_size=False. Change Environment
method cache_key() to return the same cache key when bin_size is absent,
bin_size=None or bin_size=False.
Tests on binary fields have been updated to not rely on flush and
invalidate. We also created specific tests for write() on binary
fields.
Part-of: odoo/odoo#160708
Changing the environment in method create() to force bin_size=False
looks harmless, but it actually breaks many tests, in particular in
module account. The reason is that company_dependent fields are read at
the wrong place in the cache. And this is because `env._cache_key` can
be polluted with old data.
Make sure that `_cache_key` is cleared when resetting all the lazy
properties on the environment. Only the change in res_user.py makes it
work, but let's not tempt the devil.
Side note: I hate caches.
Part-of: odoo/odoo#160708
The issue:
Currently, in Indonesia, the regulation for tax ID is 15 digits.
But a new regulation is coming where Tax ID is now 16 digits by adding 0 in front
The fix:
Remove the first zero and leave the rest for the _run_vat_test function
Related PR: #146111
opw-3782636
closesodoo/odoo#157885
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
If you create an applicability and remove the company field,
they are never used.
An applicability like this should be valid for all companies.
We put a 0.5 value for the company field so an applicability
so it has a lesser priority than other fields.
Same idea as the distribution models.
opw-3847415
closesodoo/odoo#162152
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Since 3eb9680602, the signature of method
`_notify_by_email_prepare_rendering_context` has been changed to provide
a default values to `msg_vals` and some overrides were not adapted
(or have been added afterwards).
No true bug/issue has been found caused by that discrepancy, but for
consistency, this commit makes sure those overrides are adapted to
provide the same API as the parent method.
Fixes#162742closesodoo/odoo#163418
X-original-commit: d4b31842d6c3e1c5c86d9019a353601914ebf1f7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, an error is generated when removing all product quantities from the
cart after a claiming a reward(discount).
Step to produce:
- Install a 'website_sale_loyalty' module.
- Navigate to the website / eCommerce / Loyalty / Discount & Loyalty to create
a record.
- Set the Loyalty Program name and Program Type as 'Loyalty Cards'.(Ensure it's
available on sale and the website.)
- And add 'Rewards' and set a Reward Type as 'Discount' which is applied to
on Cheapest Product.
- Go to the website shop add any product on a card, Open a cart increase the
quantity of the product, and claim the discount reward.
- Again go to Loyalty Program and open Loyalty Card, Open a record and add a
Balance(greater than 200 as default reward points are 200) and copy 'Code'.
- Again go to the website shop and apply this code to claim a discount after a
claim discount.
- Now remove all product quantity from a cart.
AttributeError: 'bool' object has no attribute 'price_unit'
The issue occurs when attempting to remove all product quantities from a cart.
At this point [1], a bool value 'False' is returned, and the system attempts to
get a value of 'price_unit' from it [2].
link [1]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L187-L195
link [2]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L205
This commit resolve issue, If the _cheapest_line() method returns False then
also returns False from _discountable_cheapest(), To raise an error at [3].
link [3]: https://github.com/odoo/odoo/blob/cbc40eccf576c499709f7825edad9a3b3ce7a22d/addons/sale_loyalty/models/sale_order.py#L317-L333
sentry-5119007021
closesodoo/odoo#163403
X-original-commit: dfd1aabb40d8c8e6e80f1b194a4b61e1dfb41608
Signed-off-by: Meet Gandhi (mega) <mega@odoo.com>
The issue:
when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback
To reproduce:
- Enable 2 currencies
- Have the exchange difference journal set to NULL (empty)
- Create an invoice with a different currency than the one set for the company
- then register a payment.
The fix:
Throw a user error indicating to set the post exchange difference journal
opw-3783917
opw-3768202
closesodoo/odoo#157735
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
closesodoo/odoo#163433
X-original-commit: d06a22991cd604e46d6392f6394b2b0e6a4ae673
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
When creating the first invoice TicketBAI chain sequence does not exists therefore it is created, if user does not belong to Administration/Settings
group, an access error is raised and invoice is not posted. In the same time, a write operation is done in the company to set the value of the sequence
on l10n_es_tbai_chain_sequence_id field, and writing in a company only is allowed for users that belongs to Administration/Settings.
With this commit:
We make a sudo in self (res.company), no errors are raised, invoice is posted and TicketBAI XML file is created and posted to the agency.
closesodoo/odoo#163432
X-original-commit: 55bb16a6b5c44a86cf20f29c4cd705bb2403ae27
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
Accidentally the test case in community inherited
class from enterprise
After this commit:
We inherit the correct class which belongs to
community
closesodoo/odoo#163399
Signed-off-by: Josse Colpaert <jco@odoo.com>
The spec for electronic invoices in Colombia was updated and is now
known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi).
This commit introduces some changes in the base module that are needed
for the Anexo 1.9 update.
task-3639271
closesodoo/odoo#151431
Related: odoo/enterprise#55279
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- create an empty spreadsheet
- type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")'
=> #ERROR
There's no account that match the given code.
The account.move.line domain ends up having a clause
`('account_id', 'in', [])`
The ORM detects the domain won't match anything and
early returns an empty list []
Our code expects a query object and not a list => boom
opw-3872445
closesodoo/odoo#163444
X-original-commit: 95de1332196fde7bfa5d178c6c0b7995cd892acb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
pengyuthon