Create a vendor bill with a specific attachment (on ticket)
Go to vendor bill list view
Select the created bill and another one
Print > Original Bills

Traceback due to unhandled ValueError on pdf read

opw-3420507

closes odoo/odoo#128454

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

closes odoo/odoo#131436

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

Incorporate Andrea Geraldo (AndreaGeraldo) as Vauxoo's contributor.

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#131437

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

Currently, configuring opening hours for event sponsors 'at midnight' is not
handled properly.

If you set either the start time or the end time opening hours to "00:00",
the sponsor will be considered as always open.

We fix that by correctly taking into account that configuration.

(Note: if the user configures a sponsor to be open 'until midnight', we assume
it means midnight 'the next day').

Tests have been altered to take this into account.

Task-3459777

closes odoo/odoo#131348

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

As the move is posted,
no editing should ever
be allowed to the expense sheet

task-3458179
opw-3446247

closes odoo/odoo#131173

Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>

before this commit, if the user profile is opened
from a particular forum, the votes tab is displaying
the votes from all the forums for this user.

where us, the questions and answers tab is filtering
the data based on the selected forum.

after this commit, the data displayed in the votes
tab will also be filtered based on selected forum,
similar to questions and answers tab.

closes odoo/odoo#127023

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

Steps to reproduce
------------------
* install l10n_de
* switch to a german company
* create an invoice
* add a line such that the account's default tax is different from the
  tax set on the line (ex, account: `8400 Erlöse 19% USt` and
  tax: `7% Umsatzsteuer`)

Attempt to confirm the invoice, you should see that you can't. The
system requires the account's default tax to be the same as the tax set
on the line. This should not be the case. It's a practice in Germany to
link a tax to an account like this, but it's not a legal requirement.

opw-3324323

closes odoo/odoo#127238

Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>

If you have large amount of product.template records (e.g. over 40k),
`hr_expense` module can't be installed as you would get MemoryError. It
would consume all memory while computing `can_be_expensed` field.

For that, using `_auto_init` to make it less of a memory hog.

closes odoo/odoo#109729

Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>

Versions:
---------
- 14.0
- 15.0

Steps to reproduce:
-------------------
- in Members app, add a membership product;
- add a "Payment Terms" on a contact (Sales & Purchase tab);
- in Membership tab click on "Buy Membership";
- add the membership product and invoice;

Issue:
------
There is no payment term on the invoice.

Cause:
------
In the invoice creation flow, the following logic is not triggered:
```py
if self.is_sale_document(include_receipts=True) and self.partner_id:
	self.invoice_payment_term_id = self.partner_id.property_payment_term_id or self.invoice_payment_term_id
```
Consequently, we have no invoice_payment_term_id.

Solution:
---------
Specify `invoice_payment_term_id` in the values used for invoice creation.

Note:
-----
This FIX solution only handles the invoice creation
from the membership module, to be as non-invasive as possible.

In version 16.0, this is handled by the account module,
which has made the `invoice_payment_term_id` field computed and dependent on `partner_id`.

opw-3382398

closes odoo/odoo#130998

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

Before this commit there are no rollback if raise.

closes odoo/odoo#130831

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

closes odoo/odoo#130631

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

Incorporate Alejandro Mellado (alejandromellado) as Vauxoo's contributor.

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#131135

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

closes odoo/odoo#131005

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

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