The `forcecreate=0` is required because the ICP will be deleted when set
to `False` (which is quite frequent for a boolean).

closes odoo/odoo#37103

X-original-commit: 255a1293
Signed-off-by: Christophe Simonis <chs@odoo.com>

When a title with boxed style (border arround title) is split (by doing
normal ENTER (and not shift ENTER which work as expected)) the title
being in inline-block for styling purpose, this give odd results (of
several title boxes on the same line).

With this commit style is changed so split title are on different lines.

opw-2070611
closes #37084

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

need seperate lines with different labels(SGST and CGST) on the invoice report and pos receipt
so use a tax group instead of repartition line

closes odoo/odoo#37080

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Before this commit, discuss widgets had to wait for the route
`mail/init_messaging`. This behaviour slowed down the loading of the
web client.

This commit solves the issue by rendering discuss widgets even when
`mail/init_messaging` hasn't been resolved. For instance, the
messaging menu displays a spinner until messaging becomes ready.

Task-Id 2072835

closes odoo/odoo#37031

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit, there was no way in the event question report
to filter out cancelled registration

After this commit, we introduce a filter for it

OPW 2072973

closes odoo/odoo#37032

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Changed the way the header selector behave when the selection changes.

Before this commit, the header selector was only checked when clicked and
was unchecked as soon as any other record was unchecked.

Now, the header selector reflects the current visible selection:
if all of the other visible selectors are checked, it will be checked.

Folded records are not considered visible, thus only records from active groups
and from the current pager will be taken into account.

closes odoo/odoo#36522

Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>

Added handling of invalid format types in multiple edition in list views.

Before this commit, in multiple edition, a field that was edited with an invalid value format
(e.g. a numeric field receiving a string value) didn't trigger a field_changed and no prompt
was shown; the record was simply idle with an dirty value.

Now, the list controller also listents for set_dirty events and automatically triggers
an error modal + discards all changes when receiving one.

Gives time to the user to enter an actual value in m2o in list views.

Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.

Now, many2ones only trigger a fieldChange when selecting a new valid value.

This rev. solves the similar issue as 801c603218, but with boolean
fields.

Scenario: select several records, select a boolean cell, press
enter to change the boolean value.

Task 2068280

Onchanges make no sense in multi edition as they would be computed
on the 'reference' record (the one use to edit), but applied on all
selected records. This rev. simply disables them in that case.

Task 2068280

Gave back focus to the last edited cell to increase usability with key nav.

Before this commit, after saving several records with multi edition in a list,
focus was lost (given to the body).

Now, last edited cell is given back the focus after multi editing.

The Date(Time)Fields listen to 'input' and 'change' events (like
all InputFields) to keep track of changes. However, the datepicker
already listens to the 'change' event. As a consequence, in multi
edition in a list view, if the user changed the value of a
date(time) field by directly editing the input, the fieldChanged
event was triggered twice, and there were 2 dialogs asking the user
if he wanted to save the change.

This rev. makes the Date(Time)Fields stop listening themselves to
'input' and 'change' events, and instead completely rely on the
datepicker widget.

Task 2068280

Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.

Task 2068280

Having those inputs enabled can lead to weird situations where a
record has been modified but can't be saved anymore (because the
user clicked on one of those record selectors to focusout the edited
row). Also we don't want the user to start multi-editing a field,
then change the selection, and then validate the changes.

Task 2068280

Before this commit, if a record was selected and another one was edited,
it was considered as multi edition.

Now, the multi edition only works if the edited record is included in the
selection; else it will be the only edited record (single edition).

Task 2068280

...when validating last row by pressing ENTER.

In single edition, we automatically add a new row when the user
edits the last one and presses ENTER. This is something we don't
want in multi edition.

Task 2068280

Fixes the way many2one fields are rendered in editable list views.

Before this commit, many2ones in readonly mode would render as links
and their widget would be considered as active even though you couldn't
edit it.

Now, they are rendered as plain text and act the same way as readonly char fields.

Fixes the way records are discarded in list views

Before this commit, clicking the "Discard changes" button in a list view
after editing a record triggered both the "field changed" and the "discard changes"
methods (resulting in 2 modals opening).

Now, all fieldChanges are prevented when trying to click "Discard changes",
and are re-applied if the click was unsuccessful (lifted left mouse button somewhere else).

Task 2068280

Let's assume an editable list view with a many2one field and 2
records: the first one has value 1, the second value 2. The user
selects all records and wants to set their many2one to value 1. It
edits the first one, sets 1 and validates the confirm dialog.

Before this rev., it didn't save anything because the 'reference'
record (the one used to edit), didn't actually changed, as we reset
the same value.

This rev. forces the write the new value on all selected records in
that case.

Task 2068280

Backport of 4b7ba864d0

After editing multiple record, we want don't want any
record selected. This commit ensures that.

Backport of 10eaf74230

Fixed crashes/incorrect behaviours in multi edition in the list views.
The solution to these problems was mainly to refactor the function
used to save multiple records.

Before this commit:
- Cancelling the confirmation dialog in multi edition caused
the edited record to be editable but disabled
- Saving an empty field in multi edition triggered a JS error
- Static confirmation message ("saving 0 valid records")

After this commit:
- Ability to cancel confirmation
- Proper error display when trying to save empty fields
- Message consistent with the situation

Backport of 1f2c64013

Adding a line in grouped listviews caused a crash in some cases.

Steps to reproduce:
- go in any grouped editable list view
- click on any "Add a line" cell, but not on the link itself
- press ENTER

Before this commit:
A crash occured. Unable to add a new line. Needed to refresh the page.

After this commit:
Line addition functionnality properly working even when selecting the outer cell

Backport of 801c603218

Pressing ENTER on a button element triggers an additionnal 'click' event.
Since this 'unwanted' click caused some issues in a few cases, we prevent it.
Moreover, there isn't currently any known case in which this event is useful.

Before this commit:
No modification of the initial behaviour on ENTER key

After this commit:
ENTER key pressed in abstract fields has its default behaviour suppressed

Before this commit, the cart recovery email displayed all lines of the order

After this commit, the email only shows relevant lines, that is
excluding deliveries for example

OPW 2072814

closes odoo/odoo#37025

X-original-commit: 234c3f56
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Have a multiwebsite setup
have stripe installed for one of the two websites

Make an order on that website and try to pay with stripe

Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP

After this commit, the payment success page is opened as we took
the request's url as the return url

OPW 2070428

closes odoo/odoo#37024

X-original-commit: 937b5c07
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

If you register online on a free event, there is an
access rights error when trying to download the ICS file
if you are connectd with public user.

`if not event` part is pointless, if event cannot be resolved,
@http.route would return a 404 anyway.
`if not event.registration_ids` does not make sense from a
functional point of view: there is no problem in generating
an .ics file for a public event that has no registrations (yet)
and the button we use to generate the .ics file is displayed
after the registration anyway.

opw-2066847

closes odoo/odoo#37012

X-origin-commit: f4ca5897
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce:
- Let's consider the portal user Pu, the project Pr and the task Ta
- Add Pu as a follower of Pr
- Log as Pu and open Ta
- Try to post a message

Bug:

An access error was raised due to the rule "res_partner: portal/public: read
access on my commercial partner".

opw:2070320

closes odoo/odoo#36960

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

'Journal Entries' stat button on 'Configuration/Accounting/Reconciliation Models'
do not consider entries which are automatically validated.

closes odoo/odoo#36169

Task: 2056926
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

In some cases, after installing a new language in rte_translator tour,
some query using ir_translation table will become very slow.

Identified query:
SELECT res_groups_users_rel.uid, res_groups_users_rel.gid
FROM res_groups_users_rel, "res_groups" LEFT JOIN "ir_translation" as "res_groups__name"
ON ("res_groups"."id" = "res_groups__name"."res_id"
AND "res_groups__name"."type" = 'model'
AND "res_groups__name"."name" = 'res.groups,name'
AND "res_groups__name"."lang" = 'en_US'
AND "res_groups__name"."value" ! '')
WHERE 1=1 AND res_groups_users_rel.uid IN (2) AND res_groups_users_rel.gid = res_groups.id
ORDER BY COALESE("res_groups__name"."value", "res_groups"."name")    OFFSET 0´

During post_install this query will become slower (between 0.7 and 2 seconds) ~50%
of the time, when this usually take less than 0.1 second.

For some tour step, this query is executed several times, making a simple
/web loading going from less than one second to more than 10 second, breaking the tour.

The main intuition behind that would be that the query plan completely fails,
mainly because postgress is to busy and doesn't have time to launch an analyse
when runbot load is high.

This commit proposes to execute a manual ANALYZE on ir_translation table
after a new language is installed. Tested with 40 builds, rte_translator never failed
with this fix.

cherry-pick of fc5934dc

closes odoo/odoo#37013

X-original-commit: 57f91453
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Be in company C1. Create the invoice I for a SO in company C2.
The invoice is created on the default account.journal for C1.
This happens when e.g. C2 is a child company of C1.
Then I is accessible from C1, but not from C2
as reading the journal violates the multi-company record rules.

Note that if company_id == False, then
self.env['account.invoice'].with_context(company_id=company_id)
    .default_get(['journal_id'])['journal_id']
returns False, and in that case, it would raise below.
To keep with the existing behaviour, we put a fallback on
self.env.user.company_id.id
which means that the values we pass are:
'company_id': False, 'journal_id': J for some J in company C
which is flaky, but won't trigger any extra errors.

opw 2068291

closes odoo/odoo#37002

X-original-commit: 427280d9
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

Revision on https://github.com/odoo/odoo/commit/923fb7aa05f0e9e0e67440073993ec36bb0f5f53

Commit above fixed an issue since v11.0 that display duplicated
messages on a website livechat window.

Forward-ported broke the livechat in v12.0 due to refactoring of mail
https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c



This commit correctly adapts fix for v12.0+.

opw-2070911

closes odoo/odoo#36947

X-original-commit: 86e9545b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Steps to reproduce the bug:
- Let's consider that warehouse A resupplies from warehouse B
- A has Outgoing Shipments in one step
- B has Outgoing Shipments in two steps
- Change Outgoing Shipments of B in one step

Bug: An integrity error was raised because route_id field is required
on model 'stock.rule'

PS Inspired from function create_resupply_routes

opw:2069163

closes odoo/odoo#36991

X-original-commit: 2a87b56e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Some operations call the WizardMultiChartsAccounts.existing_accounting
(file chart_template.py), such as going to the settings of the Accounting app.

This function tests whether any lines are present in several tables related
to accouting.

Before this commit:

a search is performed throughout the tables and takes forever for a large db.
Partner reports: "with current code, a customer with 12M account move lines
gets an out of memory error after the screen has sat for 10 minutes - this is
because the code is doing a read on every row in the account move line just to
see if the user company has a record".

After this commit:

with limit=1, the search stops after only one line is found in any table.

closes odoo/odoo#36975

Opw: 2066938
X-original-commit: 80563819
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

[FIX] account: dashboard: Center the empty dashboard message horizontally when the setup bar is displayed on a small screen

Before that, when using a small screen (with width <= 768 px) and
showing the accounting dashboard of a company without any chart of
accounts installed, the icon and message prompting to install a chart of
accounts was displayed in the lower left corner, instead of being
horizontally centered.

closes odoo/odoo#36974

X-original-commit: 4999f47d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>

-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.

closes odoo/odoo#36973

X-original-commit: 3ab4589f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Following 40487aca there was an issue
where a delivery could be splitted because of mrp specific code.

This test checks that when creating a sale order including a level 3
bom (MTO) the delivery is one, containing the correct products

closes odoo/odoo#36961

X-original-commit: c07ecea7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>