There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
'survey.user_input' model has an inherit in hr_recruitment_survey module to
link survey answers to applicants. The field is named 'applicant_id' which
leads to issues with 'default_applicant_id' is present in context. This
happens quite often when going from a kanban view notably, as it adds this
filter in context when displaying applicants. Trying to send a recruitment
survey to this applicant fails as it tries to set an ID in a o2m.
In this commit we simply remove the default value in context to avoid issues.
As anyway this model is technical it should not depend on default values.
In master we will rename the field to avoid issues.
Followup of odoo/odoo#63946
Task-3093257 (Mail: The Composer Update)
closesodoo/odoo#110958
X-original-commit: e215ae152d0d2cad315d87ef03c58599f6d20e13
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
Create a leave allocation for a group of employees
via the "By Employee Tag" mode.
Issue:
Employees have more allocations than expected.
Cause:
The allocations are confirmed automatically when
the "base" allocation record is created
(if there is not validation required).
And the "CONFIRM" button is also clicked
which does the same operation a second time.
Solution:
Do not start the validation process if the allocation
is already validated.
opw-3096138
closesodoo/odoo#110942
X-original-commit: 7d4e0c0bb3762bb5b05871b07bdb15f0f242ab0a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Right now when you create an order (order A) in a POS with tables the
`date_order` is being set correctly (in UTC, so is shown in the back-end
with the user's timezone), but after you return to the Floor Screen or go to
another order (order B) and then go back to the order A and you add
another product and the order is saved (not paid) when you check that
order in the back-end now the `date_order` it says another value not the
one of the user's.
This is happening because when the JS received the back-end information
to open the order for the second time the date come in the User's
timezone and the server's timezone, and that info was saved but taking
it like UTC.
Now instead of storing inconsistent information in the DB (server side), we
are going to modify the information that is shown in the POS (client side),
so that both sides show the same date.
This will only apply in the POS where tables are being used since the
orders are only synchronized (back-end) when the option `is_table_management`
is set in the POS (`pos.config`).
closesodoo/odoo#110832
X-original-commit: 168d0e12120ced7b1093d39b10cd79c85c56aad0
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This happended because when reloading the chatter, the chatter
changed position and its identity changes (i.e it's no longer
the same chatter). The old chatter was removed, therefore it's
invalid to access relation on removed records, e.g. with
`chatter.webRecord`.
The underlying problem was that chatter should stay the same,
even with reposition. The chatter was not properly passed
between aside to bottom position.
This commit fixes the issue by properly passing chatter in
form controller.
closesodoo/odoo#110912
X-original-commit: f04bb66c0714bf732202873e2de82bcbc767a43f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Usecase to reproduce:
- Create a product with real time valuation and AVCO or FIFO
- Create an invoice for this product without stock.move
- Validate the invoice
Traceback
It happens because it tries to check if there is a difference between
the invoice line value and the value of associated stock.move. However
in this case there is no purchase line to do the link.
Since we can't associate a picking to an invoice line magicaly. We skip
this part and let the user do his own journal entries
closesodoo/odoo#110906
X-original-commit: 8ea41cba3911fb8bcc351a4c53d2aa6c5bf7bdde
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The Record component becomes more and more used, but its API and the flows
it can support are both a work in progress.
Its specs become a little clearer, we probably want two things:
- be able to display some values via Fields widget and interact with them, in
particular relational fields.
- fetch, display and interact with a proper record in the db.
- disconnect it from the use of model in Views (via the hook useModel), because Record's
feature are simpler.
This commit aims at clarifying at least 2 aspects:
- how to pass the values to the record, that is, without reading anything from the db
=> a `values` props contains server formatted data, it supports changing them via the props
- when to reload the data from the db, when not to.
=> when props did not change, don't reload anything.
We expect further improvements on this component, as the feature is still very basic at this point.
See 475f8aa for earlier improvement
closesodoo/odoo#110122
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Install website and set in French
- in the robot wizard you see:
Exemple de règle :
Refuser : /web/login
Autoriser : *
closesodoo/odoo#110911
X-original-commit: 10e50eeeb4c3c83da2c671bd600561679fdacd44
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
On the bank reconciliation widget, we are using 2 dynamic filters "Receivable" and "Payable".
Otherwise, only one should be selected by default.
Enterprise PR: odoo/enterprise#35801closesodoo/odoo#110831
X-original-commit: 2504a623f90022dfa1c64436b7bd6e113f82e82d
Related: odoo/enterprise#36207
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, the user had to go over each expenses to
register a payment.
He now has the possibility to do so from the expense report
tree view via the "register payment" button.
task-id: 3116195
[community](https://github.com/odoo/odoo/pull/109671)
closesodoo/odoo#109671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
steps:
- Go to Rental app
- Open a rental Order
- Click on Action
- Send an SMS text message
- Fill phone number and message
- Sens SMS
Issue:
Traceback
Cause:
Sale order doesn't have a phone or mobile field so the sms.composer tries to write on it use "False"
Solution ensure the field name isn't false before writing
opw-3103232
closesodoo/odoo#110038
X-original-commit: 70a9995c9e02f36dc15d2723151ef0a205ebc12b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A recent change in owl exposes live (non-destroyed) apps on the window.
This change causes the memory used by the QUnit test suite to balloon
out of control. The reason is that when creating a mock environment, we
create a standaloneAdapter to serve as the legacy MockServer's parent,
but this standaloneAdapter creates a dummy owl application and this
application is never destroyed. This commit fixes the problem by
registering a cleanup to destroy the application at the end of the
running test.
closesodoo/odoo#110889
X-original-commit: 27ff522cd6b0c3be32be623e375052e63bb1a04f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The setting tag was introduced in [1], it was restricted to the setting
view (the js_class : base_settings).
This commit move the setting tag to the form view, to remove the
restriction and allow the use of the setting tag in any form view.
[1]: c7c2959449
Part-of: odoo/odoo#110432
This commit introduces the documentation link widget, the aim is to
standardize the help documentation links that can be found in the views.
This widget will add an icon (o_doc_link), this icon is a link to the
documentation. Note that you can use relative or absolute path. The
relative path is relative to `https://www.odoo.com/documentation/server_version`,
so it's not necessary to hard-code the server version on the arch any more.
```xml
<widget name="documentation_link" documentation="/applications/technical/web/settings/this_is_a_test.html"/>
```
Task-id: 2980478
Part-of: odoo/odoo#110432
Extracted in its own commit to ease review of next one which is fixing
the sanitize_overide mechanism.
Note that 'Escalated' is meant to be used when talking about "Privilege
Escalation Attack". It's quite misleading when someone is reading this
"error". 'Elevated' is better (confusion brought by internal team).
Since the translation will be broken by this change anyway, the chance
is taken to make it cleaner and more helpful.
X-original-commit: 34235c48bd511d68f513e747dd3f50b9ea6f46d6
Part-of: odoo/odoo#110903
Purpose:
========
This commit removes the weird blank space at the edges of the merge contact
form (using custom css that will be removed in master), and displays the
info message and the associated action button shown when there are no more
contacts to merge inside two separate rows, instead of displaying them next
to each other (by adding `colspan="2"` on these elements).
Task-3112116
closesodoo/odoo#110887
X-original-commit: eb7e5de05a5b05054bffbcf3892cf2c432e3295a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
If you limit the number of product loaded in the pos to 0, and block
loading product in the background you will have a traceback when trying
to apply a down_payment.
Steps to reproduce:
- Settings > POS > Limit products to load > Set 0
- Disable the option "Load product in the background"
- Start a PoS session
- Go in the Quotation / Order screen
- Apply a down payment
- Results in traceback
opw-3113215
closesodoo/odoo#110883
X-original-commit: 77a5e134dd3c87b3ed0bd5708bf63ed76647306b
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
An `input` wasn't clicked as it should and other DOM elements then the
expected target could be found and make the tour fail.
Task-3141104
closesodoo/odoo#110882
X-original-commit: 19013c4ea5a5d4a2bc7485b4012ba0db125b99c4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Based on RFC3462, a Content-Type text/rfc822-headers
exists and provide a mechanism to label and return
only the RFC 822 headers of a failed message (bounce)
These are only the headers and not the full message.
The Content-Type-Encoding should be either 7-bit(US-ASCII)
or Quoted-Printable (QP) as in the section 2 of the RFC.
Spawn the error:
After getting reported by a customer, I had to reproduce
by spamming wrong outlook addresses and add logging
in a sh database on the message_process of mail_thread.py
and logged the `message` variable.
After few retry, I got one of the part that was defined
as followed:
Content-Description: Undelivered Message Headers
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: quoted-printable
The `get_payload()`function used was only assuming
that there is a full email on that part and that
it could only be encoded as an email, which was not
the case in this situation (quoted-printable:
76 characters per line, character `=` used
as the end of line character).
opw-3064589
task-3131561
closesodoo/odoo#110901
X-original-commit: f86f4b671696178f8fa42b81d8753d2591578431
Signed-off-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Baptiste Vergote <bve@odoo.com>
The "All Websites" list of views is confusing for users with its
combination of default and specific views.
This commit makes the "All Websites" filter only available in debug
mode, and defaults the selected website on either the current website
(if one is selected) or the first website of the list.
The test is adapted because only the current website's pages are
displayed now.
task-3092786
closesodoo/odoo#110898
X-original-commit: 01cb743f1c0c22621bcfa92005a7d10dfa92e746
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Unfortunately, when I wrote the loc, I forgot to include
`account.group.template.csv` in `__manifest__.py`.
As such, the account groups were not loaded, and I didn't notice an
error in the chart template name.
Thanks to WAN for finding this.
closesodoo/odoo#110890
X-original-commit: 7610f1ef5f329a52ee16fe88909be30ddf395b8d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
The payment account should either be of type `asset_current` or `liability_current`, but now only `asset_current` type is allowed.
`liability_current` should also be in the payment account domain.
task-3145725
closesodoo/odoo#110846
X-original-commit: d29268c397c900774313d6069790073551458546
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color: Black and white
- BOM 1:
- product variant: P1 - White
- Type: Kit
- Consumable: C1
- BOM 2:
- product variant: P1 - Black
- Type: Kit
- Consumable: C1
- Create another kit product “P2” without variants
- Create an SO:
- Add “P1 - white”, “P1 - black”, “P2”
- Confirm the SO
- Go to the delivery → validate it Print the delivery slip
Problem:
only product "P2" is displayed in the report.
The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333
but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.
Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.
opw-3051639
opw-3047822
closesodoo/odoo#110837
X-original-commit: eae5cf84625f8155bc72b63eaed28819698810cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Well it is not a typo but a mini code improvement. The suggested diff
clarifies the intent of `_handle_control_frame` with regards to
`_get_messages`. Because it was `return self._handle...` we had to read
the method to determine if it was returning something in order to know
whether the message would be propagated to the rest of the websocket
routing by `_get_message`. Now it is clear that the control frames are
handled right away and that they are not propagated to the business.
closesodoo/odoo#110834
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: website_crm, website_form_project, website_hr_recruitment,
website_mass_mailing, website_sale
Prior to this commit, modules that add elements (fields, references,
etc.) to the website_form registry, would do so inside the
`website.assets_editor` bundle.
It creates a module dependency error since [1] + [2]:
The form options (`s_website_form/options.js`) defined in
`website.assets_wysiwyg` requires the registry defined in
`website.assets_editor`. But since [1] and [2], the
`website.assets_wysiwyg` bundle is loaded inside the iframe without
`website.assets_editor`, as only `website.assets_wysiwyg` is needed to
properly display and interact with the editor. (Although, most of the
bundle is not necessary and a later IMP will either only load the CSS
needed or split the bundle).
This commit moves the modules that creates the registry as well as
modules that extend it to the `website.assets_wysiwyg` bundle, fixing
the dependency error. Though they are not required inside the iframe,
the bundle can now be loaded without the need of assets_editor,
removing the missing dependencies. But mainly, this should have been the
case since the introduction of website.assets_wysiwyg at [3] anyway: we
want to lazy load everything that is editor related. Although it was [4]
which mixed the form editor files between the `website.assets_editor`
and `website.assets_wysiwyg` bundles.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[2]: https://github.com/odoo/odoo/commit/a154ee7ad6fd3ebdd38943e1439badae11c3151d
[3]: https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898
[4]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0declosesodoo/odoo#110811
Related: odoo/enterprise#36195
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, there is no verification while changing a product's
company. That can lead to issue where some operations cannot be done
because of access errors.
To avoid that, this commit prevents to change the product's company if
some quants for this product exist in another company's location.
How to reproduce:
- Have at least two different companies (let say CompA and CompB);
- Create a new product who belong to no company;
- For this product, add quantity on hand in a CompA location;
- Now, change the product's company for the CompB;
- While selected only the CompA, go into the Inventory Adjustments and
try to create a new inventory adjustment for the CompA location with
this product's quant -> Access Error.
opw-3095984
closesodoo/odoo#110810
X-original-commit: 46987e13f35dc140869c58f6c5a09d9c542c3ae5
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Add a constraint preventing the user from switching the project from company
if the partner doesn't belong to that company, and vice versa.
task-3126301
closesodoo/odoo#109464
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, the character `/` appears at the end of the url of the
language dropdown on the home page e.g. /en/, /fr/. This will cause one
more redirect when performing the language change.
Indeed, this error is only encountered with path = /
Please try the following `url_lang('/', 'en_US')` => /en/
After this fix, the trailing `/` will be removed when using the func
`url_lang` e.g. `url_lang('', 'en_US')` => /en, this means that the
language switching links on the homepage no longer redirect redundantly
again.
closesodoo/odoo#106109
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit project simplified view was not pretty because
of some alignment between different section/fields and width of
name field is not as expected.
This commit fix layout of project simplified view to make UX
better.
task-3102445
closesodoo/odoo#108151
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit aims to notify the user (currently through an email) that some
important security parameter of his account has changed.
Here is a list of what is currently notified:
- password change
- login change
- email change
- 2FA enabled/disabled
- trusted device (for 2FA) added/removed
This email is rather simple and only invites the end-user to take actions if
that change was not done by him (reset password, contact administrator, ...).
Task-2639168
closesodoo/odoo#94922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since e3eb7d9bef, the accounting logic
has been moved out of the payment module, to be only in the
account_payment bridge module.
This bridge module has been set as strict dependency of
module providing payment & invoicing abilities, e.g. sale .
Nevertheless, the account_payment module also held the logic to
allow users to pay for their invoices on the portal and there
was no dedicated setting to enable/disable this feature.
This means that in 16.0+, you cannot disable online invoices
payment without removing sale and subsequent modules.
This commit introduces a temporary bugfix module to allow
disabling invoices payment without uninstalling the
account_payment module. It will be merged in the core
account_payment afterwards.
opw-3114860
closesodoo/odoo#110843
X-original-commit: be242cf658e7742600dec4824ba96a89f4d6142a
Related: odoo/documentation#3396
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For companies having a Chart of Accounts that inherits from an ancestor CoA linked to the taxes, the current tax update script did not work.
This change also supports this case.
X-original-commit: 45aae69c20d40467d64af4c7e4f0b45b7832b89c
Part-of: odoo/odoo#110841
before this commit, in the draft state the l10n_de_document_title field value is computed as Repair Order and in other state it is computed as Repair Quotation.
after this commit, in draft state Repair Quotation and in other state Repair Order will be computed in field l10n_de_document_title
closesodoo/odoo#110839
X-original-commit: 522745b8cefd771c9bea8571f8f35725e817c285
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Prior to this commit the limit set on accrual plans was in hours but
effectively used as a limit in days in the code.
Meaning that a level with a limit of 240 hours effectively applied a
limit of 240 days (or 1920 hours with 8 hour days).
TaskId-3145560
closesodoo/odoo#110835
X-original-commit: c9df4a33fcfe2dbcbac35923d0bceb3757516fb1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
before this commit, the lots info shown in the products were always computed, no matter if they were printed or
not.
after this commit, the lot info only is computed when is actually used and will be printed: that is when the user has the
stock_account.group_lot_on_invoice group.
closesodoo/odoo#110808
X-original-commit: 9e95dd198790d26addfb0d30dd83d66fc1055c53
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Install Inventory & Purchase apps
2. Toggle on Settings > Inventory > Purchase Agreements and save
3. Go to Purchase
- [Products] > [Products]: add a product w/ internal reference and w/o
- [Orders] > [Blanket Orders]: create a blanket order with the products
- Save, Confirm and click Print icon to generate the said report in pdf
Desired behavior: Do not show brackets for null internal reference
opw-3138636
closesodoo/odoo#110812
X-original-commit: fb0567ee4fe75d3d0ab2475eaf1c7277ee24636a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Rémy Voet (ryv)