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

X-original-commit: b7db1dfa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

This commit enforces the use of only Cash or Bank journal types for
PoS payment methods. Before this commit, it wasn't possible to select
other journal types, but it was possible to create a journal during
the selection, with any type. This was leading to potential issues.

opw-3442317

closes odoo/odoo#130837

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Current behavior:
When a loyalty reward was applied with a promotion program, a promotion
reward was added with a -Infinity value.

Steps to reproduce:
- Create a loyalty program with a reward of 5€ fixed amount for 50
  points
- Create a promotion program with a reward of 10% discount
- Open a pos session, select a customer (and add points to the loyalty
  program if needed).
- Add a product to the order, the 10% discount should be applied
- Now click on the reward button to apply the loyalty reward
- The loyalty reward is correctly applied, but a new promotion reward
  is added with a -Infinity value.

opw-3297817

closes odoo/odoo#127770

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

In the event.registration form it can be hard to tell which event the
attendee belongs to at first sight if the event name is too long and
there are several ones with the same root.

Same approach as in https://github.com/odoo/odoo/pull/94315



TT44730

closes odoo/odoo#131504

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

Loading all partners can lead to a MemoryError.

closes odoo/odoo#126565

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

Issue:
The currency in the RFQ created from the list created RFQ on the Purchase Agreement is incorrect.

Steps to reproduce:
- Install Purchase Agreement
- Config multi currency
- Create a Purchase Agreement with multi currency (difference main currency) > Confirm
- Click smart button RFQs/Orders > Create
- RFQ will default currency is main currency

Fix:
Add a context on button `action_purchase_requisition_list` to default currency

closes odoo/odoo#130150

Signed-off-by: Tiffany Chang <tic@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#131360

X-original-commit: 61b5dd38
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

When you import a csv file with date format as DD.MM.YY you don't have
the option to select that specific date format , it's not in the list.

Steps to reproduce the error :
1-install accounting
2-go to accounting and select import on the Bank card
3-choose the file attached in the ticket
4-select Date in the field Buchungstag
5-you can see that it's date format is DD.MM.YY which doesn't exist in
the list of ´Date Format´ on the left.

Solution :
Added the required date format to the list.

opw-3425402

closes odoo/odoo#129101

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

Issues
------
All manufacturing orders are not having a start date

This commit
-----------
- Fix not updating start date on manufacturing orders.

closes odoo/odoo#128043

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

Before this commit there are no rollback if raise.

closes odoo/odoo#131281

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

The `default_pos_receivable_account_id` was missing.

opw-3435014

closes odoo/odoo#130676

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

closes odoo/odoo#131280

X-original-commit: 4c9102e8
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#131178

X-original-commit: 73ee076b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

This error occurs when the user manually attempts to change the mimetype of the
attachment, and then the base function `_postprocess_contents` tries to
determine the type and subtype of the attachment.

Error: `ValueError: not enough values to unpack (expected 2, got 1)`

To address this issue, this commit introduces a check for the mimetype of the
attachment before attempting to determine its type and subtype.

sentry-4283372480

closes odoo/odoo#128963

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

Before this commit:
When printing a receipt with an epson printers models TM-U2X0 (like
TM-U220), random characters will be printed instead of the receipt.

This happened as a picture of the receipt is sent to the IoT box, but
the TM-U2X0 models does not support all "Bit Image commands". We
currently use the GS v 0 one which is not supported by this printer
models. See:
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=94

In addition, of that, the command itself is obsolete.

After this commit:
The support for another command "ESC *" is added which is not obsolete
and supported by TM-U2X0 models.

Notes:
 - Compared to "GS v 0", the receipt printed with "ESC *" is worst:
  - It take longer to print (5 seconds vs 1 second)
  - There is consistently some thin "empty white lines"
 - Most of the code is inspired from `python-escpos`:
 https://github.com/python-escpos/python-escpos/blob/master/src/escpos/escpos.py



Due to the drawbacks, making it the default way to print would be a bad
idea. As such, we can configure the mode (with other parameters) using
particular name for the printer (which can be done by adding it manually
 with cups)

opw-3351084,3341907

closes odoo/odoo#126689

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Scenario:

- edit a mass mailing while in debug mode
- switch to codeview
- do a change
- click on save

Issue:

The body_arch is updated (making it seems like our change are taken into
account), but the body_html is not and the outdated version will be sent.

Solution:

With this change, when we commit the changes and have the codeview
opened, we will first update the wysiwyg editable to the current
codeview value, before updating body_html.

related to opw-3103549

closes odoo/odoo#119206

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

Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min

It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough

closes odoo/odoo#131169

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

`_get_starred_counter` method is obsolete now.
So, there is no meaning in keeping it anymore.

It's usecase has been removed by this PR
https://github.com/odoo/odoo/pull/83777



closes odoo/odoo#131039

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

closes odoo/odoo#130974

Signed-off-by: Sofie Gvaladze (sgv) <sgv@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#130911

X-original-commit: d20f2e2b
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Jinane Maksoud (maji) <maji@odoo.com>

Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.

Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created

Fix:
set the source Package on the return

opw-3179388

closes odoo/odoo#129505

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

On a putaway rule, the "Having Category" condition is not always
respected.

To reproduce the issue:
1. In Settings, enable:
   - Storage Locations
   - Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - L2 only:
     - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Store to: WH/Stock
   - Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
   - 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations

Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2

When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.

OPW-3437174

closes odoo/odoo#130679

Signed-off-by: Arnold Moyaux (arm) <arm@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#130926

X-original-commit: 493d31a9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

closes odoo/odoo#131037

X-original-commit: f6a996aa
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#131012

X-original-commit: 51ac0092
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>

Bug to reproduce
----------------

- Log in as admin
- Go to the frontend page of a course
- Click on 'Add Section'
- Fill the form (name input)
- Press 'Enter' or click on save button x times
x sections with the same name will be created

Specifications
--------------

Prevent the 'Add section' form being submitted multiple times in a row.

task-3432418

closes odoo/odoo#129907

Signed-off-by: Warnon Aurélien (awa) <awa@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#130589

X-original-commit: e4e2a28c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.

Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
-  Save the record.
- The server will stop running and not be accessible.

Error: ValueError: CSRF protection requires a configured database secret

sentry - 4291267997

closes odoo/odoo#128751

X-original-commit: 6d19abba
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

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

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

Before this PR, when moving the snippet's position, `d-none` gets added
which should not.

With this PR, removing the `this.$target.addClass('d-none')` from
`cleanForSave` method as it was adding `d-none` unnecessarily while
moving snippets position. The fact is snippet will be hidden if the
current user has no access to the mail group. So that case will be
handled using controllers route `/group/is_member`, if this return email
of the user, snippet is visible else the user has no access to the mail
group so we remove the snippet.

task-3107451

closes odoo/odoo#126712

X-original-commit: 9b39c52e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Before this commit
Previously, there was a bug that caused an error when a zip code containing
any character was entered.

After this commit
This bug has been fixed now.

task id- 3441139

closes odoo/odoo#130717

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

If the `_toRollback` property of the editor is assigned on its own line, it is
easier to identify which assignation caused/prevented a rollback when
debugging.

closes odoo/odoo#130745

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

X-original-commit: 2eeab8fc
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

To reproduce
============
- Activate wave transfers in settings
- In Inventory, have more than 80 delivery orders to process
- select all and try to add to new wave
- Try to select all

Select all button doesn't work

Problem
=======
in the dialog, the ListController is representing only the body so it
will only listens to the events coming from the body, while the "select all"
button is rendred in the footer.

Solution
========
bind the event listner when rendering the buttons.

opw-3420368

closes odoo/odoo#129519

Signed-off-by: Luca Vitali (luvi) <luvi@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#130640

X-original-commit: d79f072a
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

How to reproduce the bug:
------------------------

- Create a new user
- Log in as that user
- Go to a forum that don't require karma to ask a question.
- Create a new post
- On validation, you'll end up on a 404 page.

If we use the portal user instead, we see the post with a banner explaining
it has to be validated. This should be the result here too.

Specifications:
--------------

- When new users (karma = 0) create a post, redirect them to the page
relating to their question.

task-3372016

closes odoo/odoo#128382

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

Factorize a part of method in `mrp` so it can be used everywhere.

closes odoo/odoo#129573

Related: odoo/enterprise#45081
Signed-off-by: Tiffany Chang <tic@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#130497

X-original-commit: 0c3e1abd
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>

When downloading images from Google, we check the headers of the request
to see if "image/" is defined in `Content-Type`. On some websites,
`Content-Type` is not defined, leading to a traceback because we try to
access the key in the dictionary.

opw-3349774

closes odoo/odoo#130540

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>