Mock server's mail channel write method is incorrect. It assumes
the id of the channel will always be 20 while it could be anything.
closesodoo/odoo#86860
X-original-commit: 96e732f6bbc7622d50c3a969f5c2bb44c85c2b48
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The res.fake model has a partner_ids fields which
is a many2one but is used as a one2many.
closesodoo/odoo#86849
X-original-commit: 02b34c6b252c6a1d5a474c6de4e88f714a384286
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- create a contact with a very long name
- create a quotation
- in customer, type the first letter of the very long customer's name
- try to use the horizontal scroll bar
Issue:
close window on horizontal scroll
Solution:
Discriminate an horizontal scroll from a vertical scroll
A test has been added as well as the triggerScroll utility function
to allow proper tests when scrolling on elements
opw-2777443
closesodoo/odoo#86744
X-original-commit: e0b26496196bd4ee39fa06e1a3274982d2c7fb12
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Iucapad <luvi@odoo.com>
Add the possibility for portal users to manage API keys
in the frontend portal interface.
- Allow for portal users to manage their API keys if the system parameter
`portal.allow_api_keys` is set.
A settting in `res.config.settings` is added in order
to enable or disable the feature (to add/remove the system parameter)
through a compute field,
to avoid adding a new database column in standard
(as this revision targets stable 15.0).
The setting appear only in debug mode.
- Display the API keys in the portal in debug mode only
(as in the back-end for regular users, in their profile)
- The flow in the frontend is a mimic of the flow from the backend,
the wording and the look and feel is from the back-end.
closesodoo/odoo#86915
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Models can be defined by an SQL table, an SQL view or an SQL query (with
attribute _table_query). Counting records makes little sense when the
model does not correspond to a table, and actually fails when it is
defined by an SQL query.
We fix the compute method by counting records only for models where
_auto=True.
closesodoo/odoo#86913
X-original-commit: 956a0a1cc22f3f35fc128e32cb267e2baa793fb9
Signed-off-by: Raphael Collet <rco@odoo.com>
Correction that enables the display of the "unpublished" red label next to the
track name that are not published for the user of the group event manager only.
Task-2692907
closesodoo/odoo#86907
X-original-commit: 4d5f07dc5b393f15dc7c82e8af7da2cfeaf7720c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
unless there is another template to apply by default
closesodoo/odoo#86899
Task-id: 2798588
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
website_slides was relying on a model that belongs to a module
it does not depend on. This makes the single module builds fail.
Moreover, it appears this model was not even used during tests.
closesodoo/odoo#86876
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] illustration shapes are only obtained from their slug. Before
they were obtained from their URL.
After this commit the old behavior is restored as a fallback in case the
illustration shape cannot be found from its slug.
This is needed to allow importing shapes into the system from data
files.
[1]: https://github.com/odoo/odoo/commit/bde8abcfeb57c74438943e44215a7c8cb822329f
task-2793073
closesodoo/odoo#86858
X-original-commit: 91f2a989ddd7961f92a377b1bf74cc741dcbd3d0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating the results of a writeoff button for the manual reconciliation widget, debit and credit are actually inverted with regards to what will actually get created (final inversion is then done here to bring them back to the right sign: https://github.com/odoo/enterprise/blob/15.0/account_accountant/models/reconciliation_widget.py#L986). Because of that, the conditions defining whether or not the compute_all should compute refund repartition need to be inverted as well.
Note that it wasn't the case for bank reconciliation widget, for which the sign was directly right.
Before that, compute_tax_tag_invert computed a different value for the tax_tag_invert field on base and tax line (as the tax line uses the repartition type of tax_repartition_line_id, and the base line depends on debit/credit and the tax type). Hence, the tax_tag_invert values between those two lines where inconsistent, and the tax report was wrong (since we did * -1 on one of them, but not the other).
OPW 2769586
closesodoo/odoo#86870
X-original-commit: fdf448ef226ecf27685675ea4a49a4501d4f9263
Signed-off-by: Laurent Smet <las@odoo.com>
Expected behavior : The pricelist must be the one chosen by the customer on the website.
Current behavior : The price list is reset when the address is edited
Steps to reproduce the error :
First of all, you need to setup 2 pricelists on the website:
~ The first in dollars
~ The second in euros
~ Removes the group of countries from both
1. Create an order with the second price list (EURO)
2. Set your address
3. Edit your address
4. The pricelist will be changed to dollars
When you set the address for the first time, It redirects to /shop/confirm_order which
executes sale_get_order(update_pricelist=True) to correct the price list.
But when you edit the address sale_get_order(update_pricelist=True) is not executed
closesodoo/odoo#83061closesodoo/odoo#86764
X-original-commit: e5a76880320ce0606e6a0fc2a6ba776f79ce126e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Deleting an orphan translation is mostly impossible, since it requires
'write' access on the corresponding records, and checking access rights
fails because the records no longer exist!
Simply enable operations on orphan translations by ignoring the
corresponding records that do not exist. And make sure that the patch
does not allow to create orphan translations.
closesodoo/odoo#86869
X-original-commit: 454aa2587dcda2582ae58650019669ff0e8baa2c
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
Step to reproduce:
- Create leave type approved by the employee manager (and no limit
allocation)
- Set User A with user B as his manager
- Set User C as a time off Officer
- As user A request leaves of the before-mentionned type
- As user C, try to approve A's leave request
Current behaviour:
- Leave is accepted
Since V15, the groups have change and `is_officer` no longer
represent time_off all approver but time_off officer.
All approver are now timeoff Administrator and so the right
of time off officer should be limited.
Behaviour after PR:
- Error is shown to the current user explaining that he need to
be the current employee manager.
opw-2753845
closesodoo/odoo#86867
X-original-commit: e34e466970cab5a3774c24ac6380d0691cc773d2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When changing the structure of a kit, it lead to undesirable behaviors
on Odoo
Issue 01:
1. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
3. Create a purchase order PO with 2 x P_kit
4. Confirm PO and process the receipt
5. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
6. Return 1 x P_compo01
7. Go back to the PO
Error: The received quantity is 0 while it should be 1.0
When processing the return, the received quantity is recomputed, which
lead to:
https://github.com/odoo/odoo/blob/59fcb31f5a0b8136dae26b70ca0087f9b5cf3d24/addons/purchase_mrp/models/purchase_mrp.py#L29
However, since in the mean time the user added a new line in the BoM,
`_compute_kit_quantities` doesn't find any associated SM
(`bom_line_moves` is empty in [3]) and thus returns 0.
Issue 02:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
4. Create a purchase order PO with 1 x P_kit
5. Confirm PO and process the receipt
6. Edit the bill of materials of P_kit:
- Add 1 x P_compo02 in components
7. Create and Post the bill
Error: an Odoo Error is raised "ZeroDivisionError: float division by
zero"
While confirming the bill, some anglo saxo lines are generated. To do
so, the valuation of the kit is computed: [1]. In the above case, it
will lead to [2]. However, since in the mean time the user added a new
line in the BoM, `_compute_kit_quantities` doesn't find any associated
SM (`bom_line_moves` is empty in [3]) and thus returns 0. Back to [1],
the quantity is used to divide the total price -> it will raise an error
if this quantity is zero
Suggestion:
Such situations should not happen: once a product is used at least once,
it should not become a kit nor have a new structure (if it was already a
kit). Otherwise, `_compute_kit_quantities` will not correctly work since
it is not possible to take the BoM changes into consideration.
[1]
https://github.com/odoo/odoo/blob/abfe37fcea5b20f77799d9331d4d011530880669/addons/purchase_stock/models/account_invoice.py#L72-L74
[2]
https://github.com/odoo/odoo/blob/75191404788ab83645ee35b779991ea6fcdfa406/addons/purchase_mrp/models/stock_move.py#L19
[3]
https://github.com/odoo/odoo/blob/7d1af314320547ab5e37c1d97cad22992c98565b/addons/mrp/models/stock_move.py#L275-L294
OPW-2780855
closesodoo/odoo#86821
X-original-commit: 33fa43f795798276fa9d29dd0810289cbb1a2a9c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit
The style for `li.oe-nested` was loaded only when the editor loaded.
The problem is that the style needs to be visible even when the editor
has never been loaded.
After this commit
The style for `li.oe-nested` is always loaded in the backend and in
the frontend.
Task-2793528
closesodoo/odoo#86817
X-original-commit: 6c26e24c3d52410c0a3a06ee9a9d0aad6858a438
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Context
-------
Web design specific require a lot of work and need maintenance.
So far the style files were not taken into account despite the
amount of maintenance they require.
With this commit they are going to be counted,
knowing they still can be excluded in the manifest.
Imported module allow to deploy frontend assets: stylesheet,
javascript, xml template and Qweb view that require
as well some maintenance. They are going to be counted
Implementation
--------------
- Add method to parse css and scss file
- Include .scss and .css file in the count
- Add external_id to attachment that store
frontend asset of imported module
- Find all attachment with .js, .css, .scss, .xml
from imported module
- Find qweb view from imported module
- cound the content of the attachment and the qweb view
closesodoo/odoo#86816
X-original-commit: d2e0b48271dbd8cd7bbdbc5c2c1649c55c51417b
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Since [1] non-image documents uploaded in web editor were stored as
received in base64 without being decoded.
This led to downloading them as they were stored in base64.
After this commit uploaded documents are base64-decoded before being
stored.
Steps to reproduce:
- edit a web page
- drop a "Text - Image" snippet
- replace the image
- upload a document (PDF, TXT...)
- save page
- download document
=> received document was base64-encoded
[1]: https://github.com/odoo/odoo/commit/6b8752604898bf2b583b7f5334e35f6a1583595e
task-2782269
closesodoo/odoo#86812
X-original-commit: b0218b8ff50c7cea2a018d20a62e63510bfdd01e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Make the channel_type required in UI and add SQL constraint for the database.
task-2774970
closesodoo/odoo#85146
Related: odoo/upgrade#3273
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Enable “Storage Locations” option in the inventory settings
- Go to Inventory > Configuration > Warehouse > locations
- Choose any Location > Click on current stock > Select any product
- Try to add two line
Problem:
Traceback is triggered, Because the line should not be added twice(like in “Inventory Adjustments” view)
and as in the `_onchange_location_or_product_id` we access the quantity,
it should be only one quant: https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_quant.py#L517
In v14, this list view is not editable, but since the refactor in v15 added the new view `stock.quant.inventory.tree.editable`,
it is being called by this action
Solution:
set the `view_id` to `stock.quant.tree`, which is the view it was previously using
opw-2779795
closesodoo/odoo#86766
X-original-commit: 68657a85eb09dd306feab91d805b8c21eb75010f
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, mismatching types between String and Number would
cause inserts to register a change.
`rtc.js` used `rtcSession.peerToken`(String) and `rtcSession.id`(number)
interchangeably, this commit fixes this issue by favoring the usage
of `rtcSession.id` and `mail.RtcSession` when possible.
closesodoo/odoo#86580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When clicking on readonly stat button (website related), it would
sometimes raise a traceback since there is no action to redirect to.
Step to reproduce:
- Go to Website > Visitors > Visitors
- Select a Visitor to enter its form view
- Now, either:
A. Enter edit mode
B. Enter edit mode and discard (or save)
- Click on stat button
This will raise a traceback, since the `disabled` property is now gone.
Indeed, the framework is adding/removing that attribute when entering
or leaving edit mode.
See disableButtons()/enableButtons()` called by
_setEditMode()/_onDiscard()/..`
Note:
- With the new framework/owl, there is no TB as the `disabled`
attribute is not removed anymore.
- In 14.0, there is no issue despite the `disabled` attributed being
removed.
Fixes#78500Closes#80884
Courtesy of @odooaktiv
closesodoo/odoo#86552
X-original-commit: e8882fb745d140eb8d4385b7a1d0f754c78453ab
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case an open balance needs to be created on a receivable or
payable account after reconciliation, but no partner was defined
on the statement line, we want to keep the partner from the
counterpart values that was identified through reference matching.
closesodoo/odoo#86752
X-original-commit: 8c4d6d362c096e9dc67562ecd7bad0ce08bc6697
Signed-off-by: Florian Gilbert <flg@odoo.com>
Step to reproduce:
- Install contacts
- create a new contact and set "Côte d'Ivoire" as country
- add a phone number like this one: (+225) 01 02 03 04 05
- try to send a sms to the number, it's says "(Invalid number)" instead
of the number, so it's not possible to send the SMS
The Ivory Coast has a new standard for the phone number since the 31
January 2021, the phone number can have a length of ten digits. And we
use the library phonenumbers with the version 8.9.10 and 8.8.1 for the
runbot and the SaaS server, but it's quite old (the 8.9.10 is released
on Jul 12 2018). The library in version 8.12.29 resolve the issue, but
using the recommended installation method, we would not have this
version.
opw-2726582
closesodoo/odoo#86742
X-original-commit: 2f718cd78feeafb82b2d11a58e1a518a69d52c5e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
When confirming a sale order, if a purchase order is generated, the
descriptions of the PO's lines won't be adapted to the vendor
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Service
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Purchase Automatically: True
3. Create and Confirm a SO with 1 x P
4. Open the generated PO
Error: The description is incorrect (it's the standard name of P instead
of "[C01] Name01")
OPW-2777702
closesodoo/odoo#86256closesodoo/odoo#86679
X-original-commit: 77a2ad4b81c54fe6a91f2be242345c9d2af10dc0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Alexandre Kühn