Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).

Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
   wouldn't have to do that if it was in the regular testing base as it
   could not be broken. This is a waste of time for no reason, as we
   need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
   because the test need to be adapted to a theme change or something,
   but one day someone will be able to break the website core mechanisms
   (COW, theme install etc) and this will be problematic.
   Note that if this was to happen, the runbot team will be handling the
   issue and the fix with the people that broke it, as it was promised
   when we discussed about moving those tests in the regular testing
   suite. It was the conscensus for us to accept to leave those tests in
   the nightly only (we didn't really had a choice tho).

[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c



closes odoo/odoo#106026

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Setup multicurrency, with:
* rateA for dateA
* rateB for dateB (dateB > dateA)

Have an invoice in dateA with foreign currency and duplicate it.
Checking the journal entries, you should see that Debit/Credit is the
same as the source invoice. Posting the invoice would assign today date,
keeping the wrong rate.

opw-3007740

Backport of 0ac6bb4662b537ed10eaab89a6484476c421342f

closes odoo/odoo#106146

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909

Fixes 2687380
Fixes 2856101

closes odoo/odoo#103292

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Issue :
- Liechtenstein adapted the same QR-Invoice as Switzerland.
However, Odoo only allows the issuance of QR-Invoices to
swiss customers

https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills

.

Fix:
- Allow LI users to be issued QR-Invoices

OPW-2977644

closes odoo/odoo#100470

Related: odoo/enterprise#34168
Signed-off-by: Josse Colpaert <jco@odoo.com>

- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...

closes odoo/odoo#95291

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

closes odoo/odoo#105740

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The existing code was generating misleading errors for imported Odoo
modules that could not be loaded.  Although there was a specific hack
for module 'studio_customization', imported modules were not handled
properly.  This patch adds the right condition in the SQL query in the
module that introduces imported modules.

closes odoo/odoo#105955

Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce:
    - install a localization which uses the account_edi module;
    - define Lock date for the fiscal period;
    - choose an invoice which was sent before this date;
    - click on the "REQUEST EDI CANCELLATION" button.

Issue:
    We try to cancel the EDI document despite exceeding the fiscal period.

Cause:
	The verification of the fiscal period is done when clicking on the "RESET TO DRAFT" button which, in the flow, is after the request for cancellation of the EDI document.

Solution:
    Make a verification of the fiscal period when clicking on the "REQUEST EDI CANCELLATION" button.

opw-2990873

closes odoo/odoo#106014

Signed-off-by: Josse Colpaert <jco@odoo.com>

Computing account.move.payment_state relies on this field. When
perfoming payment operations in bulk (like during an upgrade) the field
computation may become too slow.

On recent upgrade cases the abscense of this index caused delays ranging
from 5 hours to whole days in the upgrade of big DBs.

closes odoo/odoo#105794

Signed-off-by: Christophe Simonis <chs@odoo.com>

Current behaviour:
When we are printing a report and then the report fails to generate
(for ex. wkhtmltopdf memory limit/timeout),
the incorrect state is committed to the database.

Expected behaviour:
We should rollback when generating reports fails, since it is an error state.

Steps to reproduce:
To reproduce the behaviour, we need to force an error state.
- In odoo/addons/base/models/ir_actions_report.py:`_run_wkhtmltopdf()`,
raise an exception before spawning the subprocess (for ex. adding a 1/0).
- In addons/web/controllers/main.py:`report_download()`#L2126,
add this little code snippet:
```python
ids = [int(x) for x in docids.split(",")]
report = request.env['ir.actions.report']._get_report_from_name(reportname)
obj = request.env[report.model].browse(ids)
if getattr(obj, 'message_post'):
    obj.message_post(body='This report was committed!')
```
- Install Inventory
- Pick a delivery order and try to print it, there should be an error
(whatever exception you decided to raise in `_run_wkhtmltopdf()`)
- See that in the message board we got a message that the report has been committed,
which isn't the case, it failed to generate.

Reason for the problem:
Controllers are catching the exception when generating reports,
but never reset the state of the database.

Fix:
Raise an InternalServerError with an error code of 500 to trigger
a database rollback.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-3001950

closes odoo/odoo#104594

Related: odoo/enterprise#33443
Signed-off-by: Julien Castiaux <juc@odoo.com>

Steps to reproduce:

  - Install `Expenses` module
  - Go to Settings > Technical > Email > Aliases
  - Edit the `expense` alias
  - Ensure the model is `Expense`
  - Set `Alias Contact Security` to `Everyone`, then save

  - Send an e-mail to the expense alias, using an e-mail address not
    referenced on one of the employees.

Issue:

  Error in logs related to `currency` variable.

Cause:

  Trying to create an expense for a non-existing user, therefore,
  no currency is set.

Solution:

  If no user is found, no need to create the expense and let the orm
  raise the error that a required field is not set (field employee on
  expense).

opw-3027350

closes odoo/odoo#105771

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Version:
V14 only

Steps to reproduce:
install Studio app (web_studio module);
inside an app create a new model with Studio;
choose the "Date & Calendar" feature for the new model;
create the model.

Issue:
An error occurs "Invalid view Default calendar view for x_modelName definition in False".

Causes:
Server log:
`odoo.tools.view_validation: <string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_INVALIDATTR: Invalid attribute edit for element calendar`
`odoo.tools.view_validation: Invalid XML: Get RNG validator and validate RNG file.`

Explanation:
".xml" files must be verified with the grammar inside the ".rng" files. The "edit" attribute is missing in the calendar tag grammar (calendar_view.rng file). This attribute is added during the validation's process of a view when it is created.

Link of the function which add the attribute: https://github.com/odoo/odoo/blob/14.0/odoo/addons/base/models/ir_ui_view.py#L899-L912



Solutions:
Add the "edit" attribute inside the "calendar_view.rng".

opw-2972415

closes odoo/odoo#100456

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Steps to reproduce:
1. Create a membership product for a period of time in the past,
 and one including the current day
2. Create a member, make him non-free
3. Create an invoice for the member for the past membership, cancel
 the invoice
4. Note that membership state is not updated to `cancelled` (Problem 1)
5. Change the `date_cancel` on membership.membership.line
 to a date in the past
6. Add an invoice for the current membership, note that the state is
 updated to `cancelled`
7. confirm the invoice and register payment, note that the state is
 not update to `paid` (Problem 2)

This line in `_compute_membership_state` causes the bug to appear:
```
if partner.membership_cancel and today > partner.membership_cancel:
    partner.membership_state = 'free' if partner.free_member else 'canceled'
    continue
```

To solve the issue, we remove the lines of code that made the state
to be stuck and use the membership lines only to calculate the correct
state.

opw-2978902

closes odoo/odoo#104178

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

In rating/controllers/main.py, the method action_submit_rating accepts
only post request. This creates a problem when you're trying to use the
web editor on the template as well as when you just paste the url in
your browser, for those are get request. The current behavior is a crash
with 'method not allowed'. This commit's purpose is to change the method
so it also accept get request. The use case of editing the feedback
rating page is arguable but it schould not crash.

The behavior after this commit is that the web editor is enable for the
page, and relaoding the page does not crash anymore.

task-3047893

closes odoo/odoo#104856

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

It is not possible to consume a component tracked by serial that comes
back from a scrap location

To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
    - P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
    - 1 x P_compo with serial SN
4. Process a manufacturing order MO:
    - Product: P_finished
    - Compo: 1 x P_compo with SN
5. Unbuild P_finished
    - It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4

Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"

When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location

OPW-3055252

closes odoo/odoo#105843

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When marking a WO as done, if the serial number defined is related to an
unbuilt product, an error will be raised and the user will not be able
to mark the WO as done

To reproduce the issue:
1. Create a BoM for product P with one operation
    - P is tracked by SN
2. Produce one P with serial S
3. Unbuild it
4. Create and confirm a second MO with 1 x P
5. Start the WO
6. On tablet view, set the finished lot to S
7. Mark the WO as done

Error: a UserError is raised because "This serial number [...] has
already been produced". However, this serial number has been unbuilt so
the worker should be able to use it again

When marking the WO as done, we check the uniqueness of the defined
serial number. But:
- The check is not accurate enough, hence the above error
- The lot of the WO is a computed/inverse field based on lot of the MO
- Once the WO closed, we can still change the lot of the MO
- When marking the MO as done, a better method checks the SN uniqueness
(does not fail in the above case)

Therefore, the checking on WO side is useless. We should let the MO side
handle this.

Moreover, let's say that there is already one P in stock with serial S2.
On tablet view, if the worker set the lot to S2, there should be a
warning so he can be aware of the situation. This is already the case on
MO side:
https://github.com/odoo/odoo/blob/45e37b2ad7bdcfd9f9f7e1dabbd0a99c9a0b5cdc/addons/mrp/models/mrp_production.py#L694-L705



(This commit is linked to a similar commit OE side, same opw)

OPW-3002424

closes odoo/odoo#104456

Related: odoo/enterprise#33377
Signed-off-by: Tiffany Chang <tic@odoo.com>

### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact

You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)

opw-3007722

closes odoo/odoo#103545

Signed-off-by: Josse Colpaert <jco@odoo.com>

Setup:

  - Add a checkbox to the sublist view of quotations with studio and save
  - In the chrome devtools, select a custom network throttling profile
    with 1s of latency

Steps to reproduce:

  First example:

  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Double click on the price field of the second line
  -> A traceback appears: `Cannot set properties of null (setting 'props')`

  Second example:
  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Click on the price field of the second line
  - Click on Save
  -> The same traceback is there

Cause of the issue:

  The checkbox field is implemented in owl and thus the
  owl_compatibility layer is used.
  Mounted is not called on the checkbox if a new rendering is being done
  cf: https://github.com/odoo/odoo/pull/75950


  Currently, it is possible to set a row mode before the previous call
  and rendering is done.

Solution:

  Use a mutex for each record to prevent simultaneous render

opw-2937444

closes odoo/odoo#101419

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
3. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO

Error: The qty received is 2, it should be 0

There is currently no code to handle the return of a dropshipped product

OPW-3030895

closes odoo/odoo#105185

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
4. In Locations, edit WH/Stock:
    - Return location: True
5. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: WH/Stock
8. Validate the return
9. Go back to the PO

Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)

In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.

OPW-3030895

Part-of: odoo/odoo#105185

When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.

OPW-2955202

closes odoo/odoo#104346

Signed-off-by: Raphael Collet <rco@odoo.com>

Steps to reproduce the error:
- Install 'Maintenance'
- Select 'Maintenance' -> 'Request Maintenance'
- Create a maintenance request:
          + TH1: Save > Change stage to Repaired > 'Close date' =
Date.Today()
          + TH2: Don't Save > Change stage to Repaired > Save > 'Close
date' = blank

closes odoo/odoo#100777

Problem: App will show 'Close Date' blank
Expected: App will display 'Close Date' as Date.Today()
Solution: When Click on Save button -> Automatically get current date as end date
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

There are specific accounts that should be used for tax groups for
each version of the CoA

t-3059059

closes odoo/odoo#105648

Signed-off-by: John Laterre (jol) <jol@odoo.com>

Fixes a small but massive typo that prevents snailmail from working on
version 14 to 15

closes odoo/odoo#105707

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.

How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice

Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.

closes odoo/odoo#104819

Task: 2852452
X-original-commit: 1e336810
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

closes odoo/odoo#105638

X-original-commit: 68f29fda
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

closes odoo/odoo#105510

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Upon updates, the `active` field of `ir.ui.view` behaves differently
depending on whether the view is defined by using the `<template>` tag
or the `<record>` tag.

When using `<record>`, it behaves like any other field and gets updated
with the new value (notice that for qweb view, you should rarely rely
on this as if users customized those views with the website builder,
they are duplicated (COW)... updating the active field without migration
script would then be a source of errors).
When using `<template>`, it is not updated since [1], except for new
records since [2].

This commit adds a comment to the `active` field to help developers find
out about this difference.

See this [discussion].

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
[discussion]: https://github.com/odoo/odoo/pull/104836#discussion_r1013155860



Related to task-2963840

closes odoo/odoo#105524

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Model `account.move.line` has extended `_name_search` to clarify `ilike` search.
However, the new domain replaces original domain, instead of making a friendship.

STEPS:
* add custom Many2one field to any form (e.g. SO)
* add domain for the field, e.g. ` [["parent_state", "!=", "draft"]]`
* try quick search for the new field

opw-3037878

closes odoo/odoo#105534

Signed-off-by: William André (wan) <wan@odoo.com>

Steps to reproduce:
- install the "Extended Adresses" module;
- in the configuration menu --> countries, edit the street format for Belgium to "  %(street_name)s" (with whitespaces)
- create a new contact;
- select a contact suggested by the auto complete feature (for example Odoo)

Issue:
    Some letters are removed if we add whitespaces in the street format (street_name field has the value "e du Laid Burniat 5" instead of "Rue du Laid Burniat 5").

Cause:
    The function which splits the raw address taking into account heading characters.
    Therefore the function truncates whatever is in front of the first field of the street format which is normally the image of the address (street_raw).

    Example 1: (correct use)
    street_raw = "header Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Rue du Laid Burniat 5" --> OK (format address is properly configured to match with street_raw)

    Example 2: (incorrect use but desired behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Laid Burniat 5" --> truncation is expected (7 leading characters are removed) (format address is not properly configured to match with street_raw)

    Example 3: (incorrect use and unwanted behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = " %(street_name)s"

    street_name = "ue du Laid Burniat 5" --> truncation is not expected (1 leading character is removed) (format address is "properly" configured but with whitespace)

Solution:
    Remove whitespaces before street format when editing this field to prevent truncation of the field value.

opw-2964457

closes odoo/odoo#99224

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

This commit fixes an issue where if a ticket is free, the registration would
still "need to be paid" by the attendee.

This behavior is contradictory for a free ticket, so the attendee now has to
pay the ticket if it is not paid and is not a free ticket.

task-3012928

closes odoo/odoo#102996

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Using the already existing indexing on the model to slightly improve the perfomance.

closes odoo/odoo#105305

X-original-commit: 4344d399
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.

opw-2976261

closes odoo/odoo#105072

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.

opw-2976261

Part-of: odoo/odoo#105072

Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.

Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled

Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.

Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.

opw-2976261

Part-of: odoo/odoo#105072

Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.

Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.

Solution:
Raise an user error when trying to save the changes.

opw-3000886

closes odoo/odoo#105291

X-original-commit: 1b2c045f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Currently, if the user uploads a facturx document whose move_type does not match the move_type chosen by the user, the document is not auto filled with the information contained in the facturx XML because of a restrictive check. Therefore, the document is empty and is sent to the OCR which acts as a backup.

Starting from this commit, we will remove this restrictive check. So, if the user uploads a facturx document, we will use the move_type define by facturx regardless of the move_type chosen by the user. This means that when we upload a facturx document, we will always use all the information that is in the xml to create the document and avoid using the OCR.

task-id 2961932

closes odoo/odoo#105287

Signed-off-by: Laurent Smet <las@odoo.com>

Steps to reproduce:
	- get into an employee appraisal;
	- click on the smart button "No meeting" from calendar view;
	- edit it directly the meeting and save.

Issue:
	We will not find any new meeting on the smart button if we go back to the employee appraisal page.

Cause:
	When saving the appraisal from the edit view, an event will be created. Unfortunately, the `res_id` field (which allows it to be linked to a record in the `hr_appraisal` table) is not correct. The smart button that is attached to the `hr_appraisal` model will not detect that there is an event.

Solution:
	Don't accept a `res_id` which is zero. If so, take the default `res_id` and update it in the dictionnary that will be used to create the event.

opw-3042573

closes odoo/odoo#104627

Related: odoo/enterprise#33510
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>