closes odoo/odoo#130977

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

Steps to reproduce:

- Install website_sale
- Go to website shop in the frontend
	- Login, Edit
	- Click on 3rd or 4th kanban item
	- Push down

Issue:

The item goes to the end of the list instead of moving one element to
the right/down. Pushing an element down searches for the next element
with a higher `website_sequence` and places the current element right
after, by switching their sequence values.

Normally the logic works fine, but the problem arises when the
`website_sale` module is installed, when records with
`website_sequence = NULL` are set to the same default value, namely
10000. Then, when an item with `website_sequence = 10000` is pushed
down, it will skip many items, before finding one with a higher
`website_sequence`.

Solution:

When updating records with `website_sequence = NULL`, assign an unique
sequence to each one. We can set the `website_sequence` relative to the
inverse of the id to ensure that the order on the shopping page remains
the same as it was prior to the fix.

opw-3318867

closes odoo/odoo#127982

Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>

When applied, this commit will restore the edition of a block when
the content has a height > 10000px.

Steps to reproduce:
1) Go to a runbot
2) Go to a blog or on the homepage
3) Enter edit mode
4) Add some text in one bloc with a total height above 10000px
5) The text will be uneditable on the top

Current behavior:
If the text is too important in one block (more than 10000px),
the text will be uneditable

Expected behavior:
The text should be accessible and editable even if the block
has too much content

opw-3393570

closes odoo/odoo#127719

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

When updating taxes, creation of taxes of type 'group' does not
work correctly if either a child or the parent itself has been deleted.
Indeed the creation of _generate_tax() method suppose that both the parent
and the child needs to be created in the same batch while we can have
databases where one of those already exists and will go in the 'update'
and not 'creation' part of the script.

closes odoo/odoo#130407

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

Remove tax demo data:
- They have the same tax name which breaks a uniqueness constraint, and
cause error at migration.
- It doesn't make sense to have taxes demo data
Also remove assignation of those taxes on other aml demo data.

closes odoo/odoo#129866

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

We now split the export of the FEC files per batch of move lines. This was necessary, as the fetchall() ran on the cursor to get the results could return a huge amount of data on big databases, saturating the RAM.

This fix is not exhaustive, and memory consumption could be lowered by removing the need to convert the whole file to base 64 and write it in attachment. Those changes are not doable in stable ; further improvements will come to master.

OPW 3442579

closes odoo/odoo#130247

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

Denmark is comprised in the EAS list but is not currently supported in
Odoo. This commit makes UBL Bis 3 available for Danish companies.

The schemeId "0184" corresponds to the "DIGSTORG" and is mandatory for
Danish Suppliers (see: rule DK-R-014,
https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-014/

).

issue-130519

closes odoo/odoo#130564

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

Before this PR, when we remove the ToC snippet, underneath the hood
navbar position of the ToC snippet was still trying to update which
should not. This is because we have bound the
`_updateTableOfContentNavbarPosition` method to scrolling events so
whenever we scroll up/down navbar position is trying to update, which is
the intended behavior when we have a ToC snippet available, but
unexpected behavior when the snippet is removed.
With this fix, we prevent that by unbound the method when the public
widget is destroyed.

task-3081442

closes odoo/odoo#108374

Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>

The user has the option to remove the last block from the Table of
Content snippet prior to this commit, but doing so breaks the Add Item
feature because there is no reference to adding a new item in the
snippet area, and doing so is also not a good idea.

If the block is the final one in the Table of Content after this commit,
removing the last Content will remove the ToC snippet.

task-3081442

Part-of: odoo/odoo#108374

before this commit, on expense report kanban view
after adding group by status, it allows the
to quick create expense report in approved
status.

after this commit, quick create is disabled

closes odoo/odoo#128831

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

The function `get_adyen_endpoints` was renamed to `_get_adyen_endpoints`
It was a typo in the method name, so it was not called and a traceback
was raised.

closes odoo/odoo#130396

Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>

Versions:
---------
- 14.0+

Steps to reproduce:
-------------------
1. Settings -> Configure document layout
2. Select the Boxed layout
3. Go to Invoices -> create a new invoice and register payment
4. Click on Preview
5. The field “Amount due” is in the wrong color and barely visible

Issue:
------
The field “Amount due” is in the wrong color and barely visible in
invoice boxed layout

Cause:
------
The issue is happening because we have `<strong>`  before the text
”Amount due” and it changes the font color to gray because of the CSS definitions

Solution:
---------
We need to make the text bold in a different way, to do it we can use the bootstrap
class font-weight-bold, this way we keep it bold and do not break the colors

OPW-3374092

closes odoo/odoo#128451

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

To reproduce the issue, follow these steps:

1. Install the Timesheet and Project.
2. From the settings menu, create a new company.
3. Create a project using the newly created company(e.g. New Company) and add
   a task to it.
4. Open the Timesheet application and create a new timesheet.
5. In the timesheet, select the project created in step 3, and observe that the
dropdown for tasks does not display any task.

Cause for this issue:
-The timesheet application has a domain set for the task field where the company
associated with the task_id should be the same as the company selected in the
current environment.
-However, when a new project is created with a 'New Company', the tasks
associated with it also have the  'New Company' assigned to them. On the other
hand, the current environment has a default company called 'Your Company'
associated with it.
-Therefore, due to this domain setting, the task field does
not display any tasks since there are no tasks associated with the
'Your Company' in the current environment.

Fix:
Since the cause of the issue is related to the company domain set in the task
field, we can solve it by removing it from the domain.

task-3323027

closes odoo/odoo#122631

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Previously, when account moves were set to auto post, and the cron was triggered to post them, if a single invoice triggered a UserError, none of them were posted (User error might be for example missing required field to post, archived journal, inactive currency, ...). This commit enables to post all valid invoices. The invoices that could not be posted are now visible on the accounting dashboard on their respective journal card with the 'to check' attribute, and a note is written on the chatter of the problematic invoices, describing the reason why the move could not be posted.

For performance reasons, we lowered the number of moves that can be posted in a single batch. This way, if a move among a batch cannot be posted, all moves of this batch must be handled one by one. Doing batch of 100 is already the case in 16.0

task-3244310

closes odoo/odoo#128420

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

Issue:
When opening the daterangepicker, but not modifying anything and
closing it, and then discarding the record, the timezone is
reapplied on the input. (value in DB is correct).

Steps to reproduce:
- Install an app that has a daterange field (ex: FSM in 14, Project
  for 15->saas-15.2)
- Edit the daterange, don't change anything, close it, discard the
  record.
- Observe the timezone has been reapplied on the input value.

Cause:
When opening the daterangepicker, the initial dates read from the
input field were already localized based on the tz, but the
daterangepicker object expect it to receive datetime in utc.

Fix:
Parse the input and make sure it's in utc.

Affected versions:
- 14.0
- 15.0
- saas-15.2

opw-3342274

closes odoo/odoo#127962

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

Bugfix. When installing l10n_eu_oss with l10n_de_skr03, an OSS account
'17010 Unsatzsteuer 19% OSS' is created. However, this account has
no account tags set on it, so it gets left out from the Balance Sheet
report. (Note that in Germany, due to there being two CoAs, the Balance
Sheet report still works using account tags.)

The solution: when creating the OSS account, re-use the account tags
of the account we are copying.

closes odoo/odoo#130185

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

closes odoo/odoo#67316

Signed-off-by: Rémy Voet (rvy) <rvy@openerp.com>

closes odoo/odoo#129862

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

When performing a manual stock revaluation, the value difference is distributed
equally among the available stock. This method breaks down however in case of a
devaluation where some items in stock are already valued less than the unit
cost difference: this results in a negative value.

This commit will prevent such devaluations by raising a UserError whenever the
remaining value of a stock.valuation.layer becomes negative. Additionally, after
a revaluation, the standard_price field will now also be updated for fifo valued
products.

opw-3340298

closes odoo/odoo#126157

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

Based on the SII documentation, DescripcionOperacion should have max 500
characters. Since it's based on invoice_origin field it can exceed this limit.

Now this value will be trimmed to the first 500 characters.

opw-3421094

closes odoo/odoo#130029

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce the bug:

- Website application
- Go to Website
- Go to menu "Pages"
- Click on "Edit Menu"
- Click on "Add Menu Item"
- Bug: This leads to a traceback.

This bug was introduced by the commit [1], where we do a
"querySelectorAll" on the anchor selector element, which doesn't
actually exist in the "Add Menu Item" dialog. The code related to adding
an anchor shouldn't be executed in this modal. This was changed in
versions higher than 14, where we separated the code used in the
"Add Menu Item" dialog from the code used for editing links in edit
mode.

In this commit, we fix this issue minimally by adding a "return"
statement if the anchor selector element doesn't exist.

[1]: https://github.com/odoo/odoo/commit/c9dbfd35ffda80f0ad07288f13ce9d0dde9591f2



opw-3422898

closes odoo/odoo#129710

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

Before this commit:

Channel was not getting unpinned after being deleted

After this commit:

Channel gets unpinned for all the channel members after being deleted

Task-2814440

closes odoo/odoo#107001

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

An action name was not translated.

closes odoo/odoo#129508

Related: odoo/enterprise#44533
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Improve low-level checks of recipients in mail asserts. Sometimes 'email_to'
cannot be easily deduced from given input (partners, records customers, ...)
when some record -> email transformations are involved e.g. when dealing
with multiple emails input, double encapsulation, ...

Those tools are about to be used in upcoming tests and fixes.

Task-3438381 (TestMail: backport tools)
Prepares Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#129508

PURPOSE

Purpose of this commit is to backport some improvements done in mail testing
tools done in newer versions. Some of them are required for incoming tests
to be added, other just to try to ease writing tests across versions.

SPECIFICATIONS

Partial backport of odoo/odoo@94208cb8b470bda745f7cbb6bc386f44d7bf14ad

Improve finding outgoing mails and emails when batch methods (mass mailing)
create similar emails, that can be distinguished notably by the subject
in addition to from / to.

Partial backport of odoo/odoo@c98f259736b5aa9c37a3580b2dad5795e8d5f6df

Add a method to check MailMail, based on a given record. When having duplicates
to differentiate in a given mailing, having just recipients is not sufficient
as multiple emails may match a given recipients list. Checking model / res_id
is another method for finding emails.

Partial backport of odoo/odoo@a3e404e17ea36447e0bbe5f92aef94e26c299366

Add some information and values propagation in some custom asserts in mail
test tooling.

Partial backport of odoo/odoo@b915617569c1de1ddef8c116aa1f7c9f66037598

Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.

Partial backport of odoo/odoo@bbf4783ac68f296dd028b46aff882b4187a0f9fb

Improve checks and asserts done when asserting content of produced
mailing content (mails, traces, ...).

Task-3438381 (TestMail: backport tools)
Prepares Task-2612945 (Mail: Defensive email formatting)

Part-of: odoo/odoo#129508

This issue occurs while uploading a PDF file and that PDF file has an unexpected
string. So, The trackback will appear.

Step reproduce :
- install the account_accountant Module
- Open Accounting Module
- Click On Customer > Invoices
- Click On Upload Button > Upload PDF file

Error:
Unexpected escaped string: b'~'

When a user uploads a PDF file, PyPDF2 does not recognise the symbol
and character combination as a valid escape sequence, such as (\), (~).

sentry-4304111635

closes odoo/odoo#128072

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

The account.move.line list view just shows the number of account
analytic tags.

With this change, we use the many2many_tags widget that will show them
directly as is done in embedded views in account.move form view.

opw-3424610

closes odoo/odoo#128430

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

closes odoo/odoo#129326

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.

opw-3413206

closes odoo/odoo#128237

Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>

Expense - Steps to reproduce the bug:
1. Create an employee whose private address is linked to the current company's partner_id
2. Create an Expense and expense report with the employee(1) with mode paid by employee
3. Confirm the Expense report and post the journal entries
4. Click "Register Payment" --> User Error occurs
5. A User Error like the following should appear (with different journal entry names):
       "Journal Entry Draft Entry PBNK1/2023/00001 (INV/2023/00005) is not valid. In order to proceed, the journal items must include one and only one receivable/payable account (with an exception of internal transfers)."

The User Error also occurs for a different scenario mentioned in https://github.com/odoo/odoo/pull/127412



According to SVFU on how the bug is fixed:
The condition that classifies the extra lines as "counterpart lines" was only intended for internal transfers.
Each company has a related "transfer account" that is used as an intermediary account for internal transfers.
Thus the old condition (c.f. commit diff) when checking whether a line is a "counterpart line"
can be replaced by checking whether the account associated with the line is the "transfer account" of our company.

closes odoo/odoo#128645

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

task-3433465

closes odoo/odoo#129140

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

Fix various issues that appeared when working with registrations. When converting
registrations to leads using rules some convert flows have issues or can crash. This
PR fixes several issues, see sub commits for more explanations.

Improve test suite to cover more use cases.

Task-3431124

closes odoo/odoo#128823

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

Partial backport of odoo/odoo@94fa8d962535a754c9fb26997a38cc8b51b8974e keeping only event_crm part as
other changes were done only for Odoo16.

In this commit we try to compare formatted phones of registration and
partner, before checking the actual phone numbers. If only formatting
differs then it is not a different number.

Task-3431124

Part-of: odoo/odoo#128823

When checking updated values of a registration to propagate to its linked lead
we may compare a recordset to IDs. This commit fixes that by always comparing
IDs.

Task-3431124

Part-of: odoo/odoo#128823
Co-authored-by: Jeremy Hennecart <jeh@odoo.com>

When checking if partner and registration have the same email, better compare
normalized versions if possible as it filters out formatting differences
e.g. if one input has a formatted email with another name.

Task-3431124

Part-of: odoo/odoo#128823

When having rules creating leads from registrations, email and phone are
copied from the registration if the linked partner has no value for those
fields. However an error in the code lead to setting phone into email which
is not really correct.

This commit also add tests for event_crm who allowed to spot other issues
which are fixed in the next commits.

Task-3431124

Part-of: odoo/odoo#128823

This patch aims to fix multiple issues with the removal of table
constraints at module uninstall.

1. We cannot remove `ir.model.constraint` records before calling
   `_module_data_uninstall` on them. Otherwise we either won't find them
   when performing the search
   `self.env['ir.model.constraint'].search([('module', 'in',
   modules.ids)]` or, if we somehow keep the ids and use `browse`
   instead, would get an error because `_module_data_uninstall` tries to
   access field values of records already removed. Note, although not an
   issue, the removal is redundant for non FK constraints since
   `_model_data_uninstall` already unlinks the record.
2. When a constraint has a name longer than 63 characters (Postgres
   default) we would fail the check for the existence of the constraint
   since the names are truncated.
3. When checking for the presence of a constraint we assumed its type
   would be `u` in `pg_constraint` because for us that means non FK
   (i.e. not `f` type). That's incorrect since there are many more
   types. Here we propose to handle `c,u,x` types.

For bullet 2 there is no simple way to ensure compliance of the name
length limit for constraints. We perform checks for table names in
standard code. There is no such alternative for constraints since their
names are enlarged by the table name, plus the `copy` method on
`ir.model.constraints` makes the name even longer. Hence we opt here to
check truncated names.

[IMP] code: improve uninstall tests

Perform extra checks for removal of SQL constraints. Note the test is
commented out in `__init__.py`. It can be uncommented locally for
testing. It's kept commented out to avoid random errors in runbot.

closes odoo/odoo#128050

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