Before this commit: In some cases where some events won't sync to
Odoo properly you got the "Unable to use a closed cursor." error. The
problem is that `_from_google_ids` function returns a recordset, and the
underlying cursor may be closed.

Steps to reproduce the issue:
 1. Create user_A and user_B in Odoo
 2. Sync user_A and user_B with Google calendar
 3. Create an event with user_B on the Google calendar
 4. Run the "Google Calendar: synchronization" cron
 5. Change the created event's owner to user_A on the Google calendar
 6. Run the "Google Calendar: synchronization" cron
=> You will get this error on the log, and the event won't sync:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/api.py", line 886, in get
    return field_cache[record._ids[0]]
KeyError: 99

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/fields.py", line 1061, in __get__
    value = env.cache.get(record, self)
  File "/home/odoo/src/odoo/odoo/api.py", line 889, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(99,).google_id'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 91, in _sync_all_google_calendar
    user.with_user(user).sudo()._sync_google_calendar(google)
  File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 70, in _sync_google_calendar
    synced_events = self.env['calendar.event']._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
  File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 147, in _sync_google2odoo
    existing = google_events.exists(self.env)
  File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 180, in exists
    events.odoo_ids(env)
  File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 88, in odoo_ids
    found = self._load_odoo_ids_from_db(env, model)
  File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in _load_odoo_ids_from_db
    mapping = {e.google_id: e.id for e in odoo_events}  # {google_id: odoo_id}
  File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in <dictcomp>
    mapping = {e.google_id: e.id for e in odoo_events}  # {google_id: odoo_id}
  File "/home/odoo/src/odoo/odoo/fields.py", line 1087, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/odoo/models.py", line 3276, in _fetch_field
    self._read(fnames)
  File "/home/odoo/src/odoo/addons/calendar/models/calendar_event.py", line 436, in _read
    super()._read(fields)
  File "/home/odoo/src/odoo/odoo/models.py", line 3343, in _read
    cr.execute(query_str, params + [sub_ids])
  File "<decorator-gen-20>", line 2, in execute
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in check
    raise psycopg2.OperationalError('Unable to use a closed cursor.')
```

The solution is to use ormcache on a function that returns the ids of the
events.

opw-3098799

closes odoo/odoo#109557

Signed-off-by: Arnaud Joset <arj@odoo.com>

When we had only one sign existing (+ or -) and tried to create
again a tag with the same name we didn't reused the existing one and
recreated two new ones.
This situation can happen after the archive/unlink of tax tags when we delete report lines
with tags still in use.
This PR improves this behavior.

closes odoo/odoo#111315

Task: 3162014
Related: #107705
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Login with admin
In Customer Invoices Journal enable ‘Factur-X (FR)’
Create an credit note. Confirm. Reset to draft.
Login with a billing user.
Open credit note, hit 'cancel entry'
Access Error will raise.

This occurs because of a new check on the attachment owner
d3a6a207

Fix backporting 8f61715e

opw-3161945

closes odoo/odoo#112116

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

This button has been broken since the start of V14.
As there is no clean way to fix this, it was decided to remove it
instead.
This change will not affect existing V14 DB unless they specificaly
update the XML or the module.

This button was broken because the sms.composer was called
with the res.model/res.id of the unique calendar event that
was active. But the overwrite of `_sms_get_default_partners`
would then return the res.ids of all the unconfirmed atendees'
partner id.

This would cause an issue a this fetch to default partner could
return multiple ids when the base id only add one and thus had called
`_compute_recipient_single` instead `_compute_recipients`

task-id : 3162304

closes odoo/odoo#111662

Signed-off-by: Arnaud Joset <arj@odoo.com>

Issue:

When activating the multicurrency in PE, the default exchange rate accounts are placed in the opposite fields (gain account should be an income account and loss account should be an expense), currently they're the other way around.

Fix:

Change the default account so Odoo created the journal entries for exchange rate differences the correct way.

Task Latam: https://latam-localizations.odoo.com/web#id=967&menu_id=88&cids=1&action=188&model=project.task&view_type=form

Reference:

https://www.noticierocontable.com/diferencia-de-cambio-venta/
https://www.noticierocontable.com/asiento-contable-perdida-diferencia-cambio/



closes odoo/odoo#112041

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

In some cases, components had dark text over dark background (or light
text over light background) by mistake.

Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
   body color instead of the expected boxed layout color (this can also
   be seen with standard "tabs" snippets, although their body is not
   buggy in that case).

This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.

In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs. Those are for example visible on the shop main
page with the price filter enabled. With a white boxed layout and dark
background, those were broken as well.

This commit focused on fixing the only critical component: nav-tabs, for
which the fix in straightforward. CSS rules that depends on `$body-bg`
in bootstrap are less easy to fix (without duplicating their rule), are
mainly less important ones and would actually not really be possible to
fix in a fully stable way. Those will be fixed only starting from 16.0
with an entirely different fix.

[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c



opw-3151962

closes odoo/odoo#111780

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

In some circonstance user can show -0.00 on taxe. It is more logical to show 0.00

closes odoo/odoo#95425

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

In case of a user have no access to all account.move (restrict by ir.rules). An exception can raise during move posting.

Add an index to speed up this function in large database.

OPW #3159258

closes odoo/odoo#111183

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

In case of an user can edit account.journal and have no access of all account.move of this journal, the user can set to false this field : restrict_mode_hash_table.

closes odoo/odoo#111184

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

After this PR https://github.com/odoo/odoo/pull/111601/commits/fe2aa862413f8ef39e7b67ca902eea02960480e3

, this method doesn't work with a recordset.

closes odoo/odoo#111920

Signed-off-by: Tiffany Chang <tic@odoo.com>
Co-authored-by: Tiffany Chang <57942143+ticodoo@users.noreply.github.com>

before this commit, the action name was not translatable into user language and always displayed in english.

after this commit, the action name will be translatable and will be showing the value based on user language preference.

closes odoo/odoo#110494

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

Strings must be trimmed in the XML output because
the Tax Agency has requisites on the length.

Specs: https://www.fatturapa.gov.it/export/documenti/fatturapa/v1.2.2/RappresentazioneTabellareFattOrdinaria.pdf
Ticket link: https://www.odoo.com/web#id=3044072&model=project.task



opw-3044072

closes odoo/odoo#107443

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

Steps to reproduce the bug:
- Create a repair:
    - Add any product to repair
    - Add any other product as part of the repair
    - Confirm the repair
    - Start the repair
    - End repair

Problem:
The cancel button becomes visible and clicking on it won't cancel the
moves, so it doesn't make sense to cancel a finished repair.

opw-3146606

closes odoo/odoo#111601

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

Fields are:

1. button_text
2. default_message
3. input_placeholder

closes odoo/odoo#75810

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

When a odoo user already exists, the installation of the deb package
fails because the `/var/lib/odoo` directory does not exists.

The reason is that the postinst script is trying to change the
permissions of this directory which is only created if a odoo user does
not already exists.

With this commit, the permission changes only occurs when the directory
is created.

closes odoo/odoo#111814

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Partner's VAT identification number now is not missing when printing Foregin Invoices.

closes odoo/odoo#110483

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

Current behavior:
When making a refund of an order in the PoS, the cost of good was
computed as if the refund was a classic order.

Steps to reproduce:
- Make sure you are in anglo-saxon accounting
- Create a category that use AVCO and automated valuation
- Create a product with a cost of 10€ that is part of the new category
- Create a PoS order with the product
- Refund the order
- Close the session, and check the accounting entries, the cost of good
  sold is 20€ instead of 0€

Note: this fix needs you to set the return picking type in the Operation
type of the PoS

opw-3149324

closes odoo/odoo#111252

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

Previously, when underconsumption occured, we split the move (in
post_inventory). And if backorder, the moves not done would be linked to
the new backorder MO (when backorder MO is created).
After 8883c06a, we create backorder MOs
before _post_inventory, making it so the moves not done will not be
linked to the backorder MOs and reserved qtys are not released.
To fix, we set cancel_backorder to be true to cancel all the leftover
moves and release the reserved qty.

Task-2697611

closes odoo/odoo#80271

closes odoo/odoo#110990

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

Considering the MO under consumption situation:
  component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
  component A, to consume = 1, consumed = 1, state done
  component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
  component A, to consume = 1, consumed = 1, state "done"
  component A, to consume = 1, consumed = 0, state "concel"

Task 2446915
PR #66583
ENT PR odoo/enterprise#16554

NOTE: this commit has been backported from [1] and, at that time, the
modified part of the test `test_basic` didn't exist. Then, the part of
the test has been added with the assert value equal to '2' and has been
modified during the FW (see [2]) so it matches with the new behaviour
introduced by [1]
Same with [3]

[1] 729db008
[2] odoo/odoo#75001
[3] odoo/odoo#75443

Part-of: odoo/odoo#110990

The calendar renderer used event.record.allday and not event.allDay
and as such doesn't use the attribute set on the view.
If the model doesn't have a field called 'allday' this can't work.
This commit fixes that.
OPW-2968130

closes odoo/odoo#110669

Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Justine Doutreloux <justine.doutreloux@acsone.eu>

Part-of: odoo/odoo#110669

closes odoo/odoo#111293

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

Part-of: odoo/odoo#111293

Starting the Odoo server with more than one worker results in repeated
"Bus unavailable" exceptions in the server log.

This seems related to the change made at
https://github.com/odoo/odoo/commit/a2ed3d3d5bdb6025a1ba14ad557a115a86413e65



 Investigation shows the the bus model file is loaded before gevented
 mode is started, and thus the wroker won't have the ImDispach
 available.

closes odoo/odoo#111352

Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>

Before this commit conditions based on `_handle_visibility` and
`_get_cached_visibility` did work only by relying on the cache of the
`menu.page_id` being populated when accessing `is_visible` in sudo.
This does not work if the cache is cleared between the calls.

This commit makes sure all 3 conditions have access the record.

The actual issue has not been reproduced locally yet.
The various workers, crons, websocket work on distinct envs - even
through code they cannot impact the cache of another local env outside
the `check_signaling` system which is only used between requests.
For the problem to occur, some intra-request multithreading is needed
but it could not be located so far.

task-3149270

closes odoo/odoo#111217

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

__Description of the issue:__

When something goes wrong while downloading a report file, a 500 error
is sent as JSON. However the frontend interprets this response as HTML
and then try to parse the text content as JSON.

Most of the time this works, but if the response contains any HTML tags,
like `<lambda>` from a Python stacktrace, the JSON response will get
misinterpreted as HTML instead of regular text, causing the subsequent
JSON interpretation to fail.

The end result for the user is that empty tracebacks will be displayed
instead of User Errors or actual tracebacks.

__Desired behavior:__

The JSON response is HTML escaped before being sent and will therefore
be correctly parsed and displayed to the user.

This basically restore what was done prior of #104594.

closes odoo/odoo#111433

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

Very similar to the usecase in commit dafe732e6874fbdd15dfd213b5c5c0cde93e534e

Steps to reproduce:

- Install Accounting, Sales, Stock
- Create a product category PC:
	- Costing method: FIFO
	- Inventory Valuation: Automated
- Create a product P:
    - Type: Storable
    - Product Category: PC
- Create a Sales Order SO with 1 x P at cost 10
- Confirm delivery
- SO > Create Invoice > Post
- SO > Return the delivery
- Change product price from 10 to 6
- SO > Create Invoice (!!)
- The invoice will be marked as a credit note automatically
- Post the invoice

Issue:

The product is listed in the journal items, which is correct,
but its value is 6 while it should be 10.

If we create the invoice from the Sales Order instead of adding a
credit note, then the move lines will not be considered reversed,
since they do not have an associated invoice.

Solution:

Consider the move type when deciding if the move line is reversed or not.

opw-3077772

closes odoo/odoo#111035

Signed-off-by: Adrien Widart <awt@odoo.com>

Current behavior:
The internal product reference is not added to the invoice when the
invoice is created from the POS.

Steps to reproduce:
- Create an order in the POS
- Validate the order and print the invoice
- Open the invoice, the internal product reference is not written on the
  invoice

opw-3119678

closes odoo/odoo#111371

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Before this commit: it was possible to create two PoS terminals in two
companies with the same `adyen_terminal_identifier`. So it's possible,
after each payment, it would add the response to the wrong payment
method's `adyen_latest_response`.

The solution is to bypass multi-company record rule in
`_check_adyen_terminal_identifier`.

opw-3131814

closes odoo/odoo#111320

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Purpose
=======
Allow to customize the Outlook endpoint to be able to use single
tenant apps.

Task-3053447

closes odoo/odoo#104795

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

Before this commit, on accessing the validation queue in the website forum,
the user image shown in the sidebar is different from the logged in user image.

The cause of issue was the variable passed from the controller and the
variable used for iterating the for loop who are the same, aka user. Thus
the value for 'user' is getting changed. resolved by storing the user value
to a temporary variable and restoring it after the loop.

After this commit, in the validation queue it will show the same logged in
user image in sidebar.

closes odoo/odoo#110904

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

Release notes: https://github.com/odoo/owl/releases/tag/v1.4.11.1



This fixes an issue with refs in iframes in firefox 109+

closes odoo/odoo#111344

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

Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
  which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
  which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
  /page URL, leading to a mismatch between the URL you created and the
  page URL.
  Your link/button will still lead to a 404 URL as it points to /Page.

Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
  the `website.redirect` and 404 cases a bit slower due to the extra
  search query.

The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page

In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.

Finally, note that another solution would have been to either:
- Force page URL to lower case.
  -> This is not stable friendly, people might be relying on this to
     create pages with different casing:
     `/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
     doesn't sounds idiot.
     On top of not being stable friendly, we probably want to keep
     offering this possibility
- Redirect all URLs to lowercase endpoints.
  -> This is obviously not stable and not Odoo's jobs. It should be
     something decided by the sysadmin and done at nginx (etc) level.

task-3110294
opw-3104030

closes odoo/odoo#109812

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

Steps to reproduce (Using Chromium-based browser > v. 108):

  - Install Survey module
  - Open 'Feedback Form' survey
  - Click on 'See Results' button
  - Try to print the 'results' of 'Feedback Form'

Issues:

  - Hundreds of empty pages added when printing.
  - Chart not fully displayed.

Cause:

  - The chartjs library add some HTML elements not displayed (inside div
  with class `chartjs-size-monitor`) to handle the resizing of the
  chart canvas.
  One of the element has a width and height of 1000000px with an
  overflow:hidden, but the overflow does not work properly when printing.
  (Issue introduced in Chrome v. 108, working fine in v. 107 or on any
  Firefox version)

  - The chart canvas is not resized to 100% of its parent container and
  therefore not fully displayed. (Not working in all Chrome and Firefox
  versions)

Solution:

  Add CSS (with print media rule):
  - Set style to `display: none` on `chartjs-size-monitor` HTML element.
  - Set the width and height of the chart canvas to 100%.

opw-3109523

closes odoo/odoo#110874

Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

opw-3073678

closes odoo/odoo#111330

Related: odoo/enterprise#36448
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

task - 3142380

closes odoo/odoo#110687

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

When sending the same survey to the same partner, the system detects it and
allows the user to choose between sending a new invitation or resending the
old one so that the user can continue the survey that might already be ongoing.
The detection was not working anymore and this fixes the problem.

Technical note: _compute_existing_partner_ids was intersecting record set
partner_ids (the one currently added) and a record set of partner for which an
invitation has already been sent. The intersection didn't work because
partner_ids relation was not completely set and instead of id, had "origin" id.
Comparing id using a filter solves the problem (using the trick that .ids,
return also the origin ids).

Task-3087702

closes odoo/odoo#108448

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

Usecase to reproduce:
- Set product as FIFO and a cost of 10$
- Sell 5 units
- Modify the cost method to average

We expect the value of the stock to remain -50$.
However it went to -150$

It happens because the change of cost method is not supported
with negative quantity of stock. It's not really a huge bug because
it will be reconcile to the real value in the next in and when the
stock will be positive again but at least it gives a proper valuation
of the inventory.

opw-3100717

closes odoo/odoo#108692

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

Steps to reproduce:
- In settings, activate "Free sign up" option;
- Go to "Sign in" page;
- Click on "Don't have an account?";
- Create an account.

Issue:
No confirmation email is sent.

Cause:
The `qcontext.get('token')` variable does not exist
in the case of a "Free sign up".
And therefore, we do not respect the condition to send an email.

opw-3103867

closes odoo/odoo#108888

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>