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#111939

X-original-commit: ad95fbdd
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

The website now being displayed in the backend of Odoo (since [1])
within an iframe. To be able to send events inside this iframe, the
`PublicRoot` widget from within the iframe is "captured" (using the
`OdooFrameContentLoaded` event). This is used to send events to Public
Widgets such as notifying them that the edition is about to start, so
they need to reload in edit mode.

Prior to this commit, the WebsiteRootInstance would be set to
`undefined` when the page was about to be unloaded (`beforeunload`
event). This is useful as this prevents the editor to start in an
inconsistent state if a user clicks on a link or changes page and clicks
edit too soon.

Unfortunately, the beforeunload event can be canceled.

Two ways this can be noticed:

- On firefox, enter edit mode and edit the page
- Try to close the tab
- A browser dialog is displayed asking the user to confirm if they want
to leave the page
- This is done using the beforeunload event
- It is triggered in both the iframe and the top window on firefox when
trying to close a tab
- Clicking on cancel won't allow you to resume the edition as the
`websiteRootInstance` was set to `undefined`

- On any browser, enter edit mode
- Upload a document using the media dialog
- Save
- Click to download the document
- Try to enter edit mode

Clicking on the link triggers a `beforeunload` as the browser is about
to leave the page. The browser somehow detects a download and cancels
the beforeunload. But the `websiteRootInstance` was already set to
undefined.

This commit fixes that by only setting the websiteRootInstance to
undefined in some context:

- When clicking on a link that will result in navigating inside the
iframe
- When changing website
- When the `WebsitePreview` component is asked to reload the iframe
- Doing it again when a `pagehide` event is triggered.

This last one is only for safety (e.g. if a widget within the iframe
triggers navigation which leads to a pagehide). Though using this event
is often too late, as the editor has time to start but often not fully,
and destroying it so early can lead to tracebacks.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b



task-3046473

closes odoo/odoo#105884

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

The `_disable_recursion` wasn't working properly because it didn't
disable recursive calls if they used the context of a recordset that is
not in the container. It is really easy to do if we use `self` for
instance.
In order to avoid this, we just temporarily change the context of all
environments while inside of the context manager.

opw-3016530

closes odoo/odoo#103286

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

When we paste content in the editor, we merge the first and/or the last
element(s) from the clipboard with the element(s) before/after the
selection (eg, pasting `<p>b</p>` at `<p>a[]c</p>` (where `[]` is the
selection) should result in `<p>ab[]c</p>` rather than
`<p>a</p><p>b</p><p>c</p>`). If the element we try to merge is a table
though, we may end up pasting a `<tbody>` without its parent table,
which leads to unexpected results. In any case we don't ever want to
merge a table with another element, so we prevent that.

Steps to reproduce the issue (in the `note` module):
* Type "a" then hit the ENTER key.
* Add a table (using the /table command) and write in each of its cells.
* Make a selection that starts before "a", and ends after the last
  character of the last cell of the table.
* Copy the selection.
* Paste the selection in the paragraph after the table.
What you see before this commit is the text you copied, without the
table.

Everything above is also true of lists (just replace the table with a
list in the text above) and these cases are fixed here in the same way.

task-3165836

closes odoo/odoo#111983

Signed-off-by: David Monjoie (dmo) <dmo@odoo.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#111974

X-original-commit: 6aa80ca6
Signed-off-by: John Laterre (jol) <jol@odoo.com>

before this commit, traceback is raised when trying to create accrued revenue entry without entering the order lines.

open a sale order, enter customer and save it, from the action button, click Accrued Revenue Entry and enter an amount in the amount field, exception will be raised.

after this commit, no exception will be raised.

closes odoo/odoo#111961

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

before this commit title for full composer dialog window is "Odoo". it increases probability of mistake for user because it doesn't clear that user do: sending email or logging note

after this commit title matches dialog purpose

closes odoo/odoo#111945

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

Before it wasn't done for simplicity, but turns out it is actually quite
simple to do.

task-3167055

closes odoo/odoo#111680

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

It is wrong in 15.0 since double clicking on the link does nothing
anymore, as edition of the link is done via the popover. Having both
tooltips at the same time created a race condition that ended up
inserting the second tooltip in the DOM, where it obviously couldn't
function properly anymore.

opw-3147108

closes odoo/odoo#111614

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

How to reproduce
=================

When entering a very long table name and / or a very long table name on
the point of sale application, the text displayed on the "go back" button of the interface will overflow,
making the name unreadable and not very pleasing to see.

How the fix works
=================

The fix just cut and hide the part of the text that is overflowing

opw-3102914

closes odoo/odoo#110970

X-original-commit: 5fce82e6
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Some html structures are not well mirrored in RTL directions.
Fix it by changing it to rtl frienldy structure.

STEPS:
* switch to any RTL language
* open list view for any model
* click Action -> Export

opw-3063763

closes odoo/odoo#110867

Signed-off-by: Luca Vitali <luvi@odoo.com>

When resetting a payment/move to draft, the related entries are unreconciled. The 'reconciled entries' button raises an error since there isn't any.

This is due to the field `has_reconciled_entries` being wrongly computed since the `_reconciled_lines()` method doesn't actually filter on lines that are reconciled.

Fixing this removes the button when there is no reconciled lines, and avoids the errors raised.

task id=3120327

closes odoo/odoo#109276

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

opw-3097856

closes odoo/odoo#111917

X-original-commit: 485e9dc6f2225da00d28f9487867e563519f7f48
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before this commit: if a non-admin user captured a payment with
PoS Stripe, an error occurred in UI. The problem is that only the
"Administration / Settings" group can have access to the payment
provider.

The solution is to use super user mode.

opw-3120441

closes odoo/odoo#111747

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

Steps to reproduce:

- Setup an accrual plan with yealy first of Jan granting 15 leaves and it will pospone maximum 7
leaves to the next year.
- Setup an allocation with date started 2 years ago on first of Jan.
- Run scheduled action "Accrual Time: Updates the number of time off" after current year first of
Jan.

Current behaviour:
Only granted 7 days leaves.

Expected behaviour:
It should grant 22 days leaves as it should combined the postpone 7 days leaves and the leaves
granted on first of Jan of the current year.

Explanation:
With this modifiation there are two changes:

1) The lastcall and nextcall in the _end_of_year_accrual method should not skipped the
_process_accrual_plans methods in the _update_accrual method for all the allocations that using
pospone action_with_unused_accruals. It should keep the lastcall as previous date of current
level or the lastcall of the allocation depending with one is latest. Also the nextcall should be
the upcoming nextcall. Therefore after the postpone_max_days caluclated. The _update_accrual
method can compute the leaves again for yearly first of Jan accrual plan.

2) The prorata amount accrual plan calculation should be date_to first_date_this_year. Otherwise
one day is missing in the prorata calculation and the leaves count will be incorrect.

closes odoo/odoo#111434

X-original-commit: 11713bfb
Signed-off-by: Kevin Baptiste <kba@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/66ca47d10 [FIX] Cell/clipboard: Fix last cell deletion
https://github.com/odoo/o-spreadsheet/commit/29fbbdd97 [REF/IMP] figure: refactor figure container and handle scroll
https://github.com/odoo/o-spreadsheet/commit/7e4c5cd9b [REF] sheetview: split getter "getActiveSheetScrollInfo"
https://github.com/odoo/o-spreadsheet/commit/bbcd4a62e [FIX] menu: use capture for events
https://github.com/odoo/o-spreadsheet/commit/f44a32e82 [FIX] Renderer: Speed up rendering
https://github.com/odoo/o-spreadsheet/commit/cd1f96ae7 [FIX] components: Fix static colors for spreadsheet
https://github.com/odoo/o-spreadsheet/commit/c5363ee81

 [FIX] drag & drop: mouse outside the grid & freeze panes

closes odoo/odoo#111951

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

The issue occurs when a computed field depends on a many2many field with
a corresponding inverse field on its comodel.  Consider two models like

class User(models.Model):
    _name = _description = 'test_new_api.user'

    group_ids = fields.Many2many('test_new_api.group')
    group_count = fields.Integer(compute='_compute_group_count', store=True)

    @api.depends('group_ids')
    def _compute_group_count(self):
        for user in self:
            user.group_count = len(user.group_ids)

class Group(models.Model):
    _name = _description = 'test_new_api.group'

    user_ids = fields.Many2many('test_new_api.user')

When a user is added to a group with

    group.write({'user_ids': [Command.link(user.id)]})

we expect the field `group_count` to be recomputed on `user` only, but
it is actually triggered on *all* the records in `group.user_ids`.  This
is a real performance issue when there are many records in the relation.

The explanation comes from the fact that
 - the framework considers the field `user_ids` is modified on `group`;
 - the field `group_count` implicitly depends on `group_ids.user_ids`,
   which makes it triggered on the users `u` such that `u.group_ids`
   intersects `group`.

The solution consists in handling the dependencies on inverse many2many
field in the field itself.  The field no longer adds the implicit
dependency on its inverse field in the trigger tree, but instead
determines which records in the comodel are actually impacted by the
relation change in the method field.write().

closes odoo/odoo#111653

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

The class is a simple extension of dict, and adds an explicit attribute
for the content of the root node of a tree.  It makes the code much more
readable with very small performance overhead.

closes odoo/odoo#111651

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

This patch optimizes the way field trigger trees are computed.  Overall,
the resulting trigger trees are mostly identical, but they can now be
determined one by one, which enables an on-demand approach and partial
cache.

Before this patch, getting the first trigger tree proceeded as follows:
 - resolve the dependencies of all fields;
 - compute the transitive closure of the dependencies of all fields;
 - store the transitive closure above as field triggers for all fields
   in a cache.

After this patch, getting the first trigger tree proceeded as follows:
 - resolve the dependencies of all fields;
 - cache them as direct triggers for all fields;
 - compute one trigger tree as the transitive closure of the field's
   triggers, and cache it.

This optimization is quite effective during the installation of modules,
and is even more effective when the number of fields is large.  For
instance, a complete installation with all community modules is now 25%
faster.  For a complete installation with all enterprise modules, the
installation time is even 30% less!  A medium installation is about 16%
less time.

The optimization also speeds up the first request on a new Odoo worker,
since the minimum time for computing a handful of trigger trees is much
smaller than before.  We have measured times for a first request going
from 1.6 seconds to 1 second for posting a message.

We have observed slight differences in trigger trees, but they occur in
places where the tree has redundant branches, in particular with fields
having recursive dependencies.  It therefore makes no difference in what
is being triggered or invalidated.

Part-of: odoo/odoo#111651

Those APIs are aimed at hiding the implementation of trigger trees,
dependent fields and fields modifying relations.  Explicit APIs simplify
the profiling of executions and comparison of implementations for
building trigger trees.

Part-of: odoo/odoo#111651

The field ir.rule.global depends on ir.rule.groups, and its inverse
field res.group.rule_groups depends on ir.rule.global because of a
domain on the field.  As the domain is only useful client-side, turn the
domain into a string, so that it is only valid client-side.

Part-of: odoo/odoo#111651

Steps to reproduce:
Realize the process checkout flow on ecommerce.
Taking care to have only one shipping method (example Mondial relay).

Issue:
When confirming the order,
it is not possible to choose another parcel point.

Solution:
Make it possible to click on the shipping method
to change the parcel point.

Remark:
It is only possible to confirm the relay point once.
We must reload the page if we want to modify it.

opw-3149294

closes odoo/odoo#111893

X-original-commit: cce78ebc
Signed-off-by: Xavier Bol (xbo) <xbo@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#111922

X-original-commit: b62e3d03
Signed-off-by: Josse Colpaert <jco@odoo.com>

Commit [1] improved the url dependencies search behavior to include more
models to search in but also the multi record capability (needed for
multi delete in list view now that website is in the backend).

But a line of code was badly designed, making the perfs horrible.
That line code shouldn't have been part of the loop as it doesn't
depend of the loop.

This was drastically more impactful on the `/` page.

Benchmark: for the `/` page, searching in 1000 product template website
           description will go from 29.74 seconds to 0.29 seconds.
           See the speedscope result on the PR description.
           For ~10.000 products, it will go from ~7 minutes to 1.35s.

[1]: https://github.com/odoo/odoo/commit/6ac17b93437868cbefbe13448a6fcbb29953f221



task-3169378

closes odoo/odoo#111919

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

When creating a SM from a SML, if the product is a kit, we should
force the state to `draft`. That way, we will go through the
confirmation process and, thus, through the 'explode' step. This
change is needed for a fix OE-side (see linked PR)

OPW-3015933

closes odoo/odoo#111881

X-original-commit: 879ef5ef
Related: odoo/enterprise#36682
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Before this commit, _onClipboardCut removed the selected text but did not
register it as a history step. Other than not storing history properly,
this caused unexpected behavior when followed by an action that leads to a
historyRollback on the current step, such as those in _onInput.

task-3142995

closes odoo/odoo#110453

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Steps to reproduce:
- have a Swiss configuration for qr-code
1) make sure your customer company is in Switzerland and has all the address information
2) make sure the customer set an Invoicing address in Switzerland (address + Country)
3) have set for your bank account in in Accounting/Journals/Bank: the Iban AND the QR iban
- create an invoice for a Swiss client
* monthly
* confirm
- Preview the invoice

Issue:
error, we should able to see the invoice without qr code.

Solution:
the user will still see the error when trying to print the invoice

opw-3104890

closes odoo/odoo#109009

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

closes odoo/odoo#104409

Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

Before this commit:

On mobile view the toolbar icon gets hidden, which it should not.

After this commit:

Now the toolbar items are flexed and wrapped.

Task-2752096

closes odoo/odoo#111849

X-original-commit: d3e6797f
Signed-off-by: David Monjoie (dmo) <dmo@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#111846

X-original-commit: 8e1ebd8d
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

We need German states when formatting the 'SteurNummer'.
So we provide it so the user can select his, instead of having to
 create them by hand.

task-3056694
opw-2974560

closes odoo/odoo#111788

X-original-commit: c741637f
Related: odoo/enterprise#36649
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>

`board` module allows adding current tree view to My Dashboard menu. It copies
some settings (context, domain, etc.), but not the list view id. Because of
that, default list view is used. However, the default list view might be
different from what user sees in original menu. For example, there are two tree
views for `purchase.order`:

`purchase_order_tree`
https://github.com/odoo/odoo/blob/6b101d5ff0ad78b9ae2ad312f362c2224e7af457/addons/purchase/views/purchase_views.xml#L535

`purchase_order_view_tree`
https://github.com/odoo/odoo/blob/6b101d5ff0ad78b9ae2ad312f362c2224e7af457/addons/purchase/views/purchase_views.xml#L599

But only one of them has field `receipt_status`
https://github.com/odoo/odoo/blob/6b101d5ff0ad78b9ae2ad312f362c2224e7af457/addons/purchase_stock/views/purchase_views.xml#L91



So, that field wasn't available in the Dashboard, which is quite annoying.

Fix it by forcing `viewId`.

STEPS:
- Click on Purchase App > Go to 'Purchase Orders'
- enable all the columns to show in listview (from that 2 arrows of listview on right side corner)
- Once you enable visibility of all columns in listview for Purchase orders list. Just Go to Favourites -> Save to Dashboard, give any name
- Reload the browser.
- Open Dashboard , go to My Dashboard
- Now see the customer dashboard which you create with certain columns is not visible in this Dashboard listview. and no way to make it visible even.

opw-3130088

closes odoo/odoo#111470

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

To Reproduce
============
- set cash rounding method to half-up with a value (1 for example)
- create a product available on pos with price (1.61$ in my example)
- on pos select this product and proceed to payment with cash
- with 2$ cash the total will be 1$ and change 1$ which is wrong

Problem
=======
- the function responsible on applying the rounding method doesn't take into
account the rounding method `"HALF-UP"`

Solution
========
- update the function to apply `"HALF-UP"` correctly

opw-3143698

closes odoo/odoo#111469

Signed-off-by: abla001 <abla@odoo.com>

When auto-fill the duration of workorders in immediate production, the
workorder cost is not included in the price of the product.
It happens becuase we calculate the price in _post_inventory but we set
the duration after _post_inventory. To fix, we set the duration of the
workorders in before _post_inventory.

closes odoo/odoo#111804

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

When count_limit is set and lower than the current number of fetched records, making an extra search_count is useless.

closes odoo/odoo#111557

Signed-off-by: Rémy Voet <ryv@odoo.com>

before this commit, on closing/confirming a blanket order by a purchase user throws access right on product_supplierinfo model.

after this commit, access right error will not be shown on confirming and closing the blanket order.

closes odoo/odoo#111249

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

Before this commit:
- Let's say we are in January 2023
- User's TZ has an offset from UTC (say UTC+2)
- Purchase > Create an rfq
- Set order deadline to 1st of next month (February), at 0.05am
- Add some products
- Confirm order
- Go to Reporting > Purchase then pivot view
- Add a filter on Order Date for the current month (January)
- Collapse the row groupbys
- Group the rows by Order Data > Month
- You can see the record of February and it should not be seeable.

After this commit
- the date range is now properly computed

closes odoo/odoo#111827

X-original-commit: 20c9e473419b92bbed01617c494b75847c60eea9
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Kristjan Tehu <kristjan.tehu@estpos.ee>

X-original-commit: f1a82a15bcaca134d4e9c315ec68027de5ee1457
Part-of: odoo/odoo#111827

When you create or update a partner from the POS, it will call the
server to get the new modifications on partners.

When you put a limit to 0 and so no background loading. You don't get
any partners and when you create or update one, it will try to load all
of your partners because the last write_date is unknown. Which is not
the intended behaviour.

If you have set a limit different than 0, you will not get all of them
(because you already have some records but it can take a larger batch
than the one defined.

So we are now trying to correctly handle the load of new partners.

closes odoo/odoo#111749

Signed-off-by: Masereel Pierre <pim@odoo.com>