- Create an Order, send to customer
- Create an invoice from this sale
--> Issue the customer can show the invoice in draft mode
This prevent customer to print a draft invoice with wrong value.

Only show send invoice.

closes odoo/odoo#114733

X-original-commit: 687f4792
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

To reproduce the issue:
1. Create user with no access rights apart from user rights in Sales,
   Sign, Project and Timesheet
2. Create a project, add a task inside and link an analytic account
   to the project
3. Create an RFQ, add a product linked to the analytic account
4. Confirm order, receive product, validate, create bill
5. Log in with user
6. Try to access the analytic account through:
   Project->Task->project name->Settings->Analytic account
7. An error message pops-up "You are not allowed to access Purchase
   Order (purchase.order) records."

Error: You should be able to access the analytic account, but the
Purchase Order smart button should not be visible/present

The data access by the smart button was not stopped by rules or
groups, thus data was always trying to be loaded, even when the user
did not have the access rights

OPW-3180788

closes odoo/odoo#114701

Signed-off-by: Adrien Widart <awt@odoo.com>

Steps to reproduce:

- Install purchase and discuss.
- Go to the purchase list view.
- You will see the purchase lines in bold.

Issue:

The bold lines are supposed to indicate that we have unreaded messages
in the chatter, but they are not working as expected, and instead it is
mixed with discuss, and they bold line won't dissappear until we send a
message in discuss.

Solution:

We removed from the views the "feature" of showing bold lines as it is
not well implemented, and it is not working as expected. This will avoid
confusion for the clients on not knowing what it is for, and when it's
bold or when it's not. Also this feature was removed in future versions.

Extra info:

If you don't have any lines in bold, and you realize they don't appear
when you send messages through the chatter. The easiest way I found to
test it is removing `cp.channel_id = msg.res_id AND ` from the SQL query
in the code inside `_compute_message_unread`. With this you will see the
bold row whenever you send a message in the chatter, but it won't
dissappear when you open the RfQ.

Forward bot up to saas-15.2.

opw-3185071

closes odoo/odoo#114288

X-original-commit: 8741db1a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>

Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.

Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.

Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
  - PackOf10 with quantity of 10
  - PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging

Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.

Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.

Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-3002612

closes odoo/odoo#107223

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

2-steps delivery. If there is already a backorder for the picking
out->customer, when decreasing the SOL qty, an unexpected picking
will be created

To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
   - Outgoing: 2 steps
3. Create a storable product P
4. Update the on hand qty:
   - 10 x P at WH/Stock
5. Create and confirm a SO with 10 x P
6. Process the pickings with 6 x P (with backorders)
   - There should be 4 pickings
7. On the SO, decrease the quantity to 7

Error: an unexpected picking (customer -> out) is created for 3 x P

Step 6, when creating a backorder for 4 x P from out to customer,
we split the initial SM, and we force the `procure_method` to
`make_to_stock`
Step 7, when decreasing the qty, we create a negative procurement
and run the rules' system. Because of warehouse configuration, the
rule that links output location and customer one is based on an MTO
logic: the SM for -3 x P has the `procure_method` set to
`make_to_order`. As a result, that move will not be merged with the
one created during the split (step 6) and we will create the
unexpected picking for the move.

The SM generated by the split should keep the same procure method
logic as the initial one.

OPW-3141387

closes odoo/odoo#114686

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

If an invoice is send to the Tax Agency, we should block the fact
that the user can delete it. In that case, we can have issues when
the tax agency sends back notifications.

Task link: https://www.odoo.com/web#id=3192962&model=project.task


Task-3192962

closes odoo/odoo#114667

X-original-commit: 0c1113e0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

Before this commit, the cancel button is visible in the done state and
on clicking showing the validation that it cannot be cancelled.

by the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f
one of the cancel button in the form is made hidden in the done state,
similarly applying for the other cancel button also.

also currently on trying to delete a done repair order, it says to
cancel first and then delete the order, from the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f


cancelling a done record is prevented, thus modifying the warning
message and its related pot file

After this commit, the cancel button will not be visible in the done
state.

closes odoo/odoo#114693

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

Steps to reproduce:
- select a different company from the main one
- under settings/discuss enable External Email Servers
- set up an alias domain
- create an SO and send it by email
(you can catch the sent email using mailhog)
- reply to that email
(you can use the support-tools[1] and set In-Reply-To: "previous message_id")

Bug:
the reply_to field of incoming message defaults to the first company

Fix:
set the reply_to field to the company asociated to the record
(there's already a fallback to self.env.company  in
"_notify_get_reply_to_formatted_email")

opw-3060214
[1]: https://github.com/odoo/support-tools/tree/master/scripts/mail



closes odoo/odoo#114680

X-original-commit: 74893cf2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Consider a form view with a one2many field, which has no form subview.
Also the form view of the comodel (the one2many field's lines) contains
the inverse many2one field of the one2many field.  When adding a new
line on some existing record, the form view shows the many2one field as
empty, instead of being the main record.

Explanation: the form view of the line invokes onchange() with the main
record's values (dict) as the value of the many2one field.  Inside
onchange(), the field is actually set to a new record corresponding to
the main record.  Alas, when that value is sent back to the form, the
new record is serialized as False.

Solution: let onchange() serialize the new record as its origin record
instead.

closes odoo/odoo#114633

X-original-commit: d137ea49
Signed-off-by: Raphael Collet <rco@odoo.com>

Bootstrap tables can basically be customized with the `$table-bg` and
`$table-color` variables. The problem is that, by default, BS4 defines
them so that the background-color is null (so transparent: displaying
the background-color of its ancestors) but the color is forced to the
body color (by default: white). This is a problem as soon as the
ancestors background colors are a color close to the body text color:
the text becomes invisible. For instance, in website:
- Set a body background color to black, the body text will automatically
  become white.
- Add a table in a snippet: still ok, the text in the table is white
  over the black body (the table being transparent).
- Then set the snippet background to white -> the table text will still
  be white... but now over a white background.

This should be reviewed in master: it should be ok to set the variable
$table-color to `null` thus letting the table be transparent and have
the same text color as its parent. But in stable, changing a color
variable to `null` could break customizations relying on the fact this
is a set color. It would also not make sense if the user set up a
`$table-bg` value going well with table text forced to the body color.
Instead, here, in the very specific case we have a transparent table bg
and table color equal to the body color, we temporarily unset the table
color variable for the duration of the bootstrap table rules.
Note: we cannot create a rule in an "Odoo file" to fix this as unsetting
the color for the `.table` rule would also unset the color in the case
of a `.table.bg-XXX` where we still want `.bg-XXX` to force the color.

task-2728923
opw-3048306
opw-3180568

closes odoo/odoo#114623

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

Before this commit: if you had a pos order with one product and one
quantity, it wasn't possible to refund less that one quantity.

Steps to reproduce:
 1. Create POS order with any product -> Qty = 1.0
 2. Go to the refund page -> Select Order -> Update Qty to 0.5 -> Click
 on the 'Refund' button

The solution is to keep the input quantity in case of a single product
refund.

issue https://github.com/odoo/odoo/issues/112291



closes odoo/odoo#112810

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

To reproduce the issue:
1. In Accounting, settings, activate Analytic Accounting
2. Head over to the purchase module, create an RFQ
3. Add a POL to the RFQ, with an analytic account specified
4. Save the RFQ
5. Edit the RFQ, and change the Order Deadline
6. The analytic account in the POL has disappeared

Error: The analytic account should not disappear

When modifying the deadline, the analytic account was always
being replaced, even if the replacement was empty.

In the same version (14.0), the same fix can be found in AML:
https://github.com/odoo/odoo/blob/1dcd071b27779e7d6d8f536c7dce7002d27212ba/addons/account/models/account_move.py#L3583-L3584

In 16.0, the issue doesn't need to be fixed, as it has already
been fixed, by a similar fix, as seen in POL:
https://github.com/odoo/odoo/blob/c677f45dcb050ce7e6f755b71e56c9b9120bf613/addons/purchase/models/purchase.py#L1153



OPW-3159905

closes odoo/odoo#114523

X-original-commit: 6b300286
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>

If you specify an empty VAT number in the Contacts app, it will store it
as `False` in the ORM. If a new partner is created through the shop, the
VAT number is set through HTML form submission. It will use `''` for an
empty VAT number. When evaluating the VAT number in Python code, it will
usually be converted to a boolean, so it doesn't matter if it's `False`
or `''`. But in ORM queries those are two different values and code that
checks on `False` to check for the presence of a VAT number can
misinterpret `''` as being one.

This fix replaces `''` values submitted through the address form in the
shop with `False`.

opw-3114246

closes odoo/odoo#114570

X-original-commit: db701c21
Signed-off-by: Merel Geens <mege@odoo.com>

Before this commit, the customize panel backdrop did not fully cover the
customize panel when the vertical scrollbar was scrolled to the bottom.

Steps to reproduce the bug:

- In website edit mode, add a table of content snippet to the page.
- Add a three columns snippet within the table of content.
- Click on an image in the three columns snippet.
- Scroll the customize panel to the bottom and open the filter selector
of the image.
- Bug: the backdrop does not fully cover the customization panel.

task-3090626

closes odoo/odoo#114507

X-original-commit: 672a8cb1
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

*: web_tour, website_blog

Since [1] when the search box autocomplete was introduced, the URL
parameters are implicitly included into the RPC that fetches the
autocompletion results.
Those parameters were not correctly unescaped before being sent to the
RPC call.
Because of this, a timestamp such as "2023-01-01 23:00:00" was sent as
"2023-01-01+23%3A00%3A00" to the server. If that string reached the SQL
layer, the "+" was interpreted as defining a timezone.

This commit unescapes the URL parameters before using them in the RPC.
Note that javascript's `decodeURIComponent` does not handle the '+'
encoding of spaces inside URL parameters.

For testing purpose, the following updates were needed to make it
possible to select the `<option>` within the Archive month `<select>`:
- because the `option`s are in a tree, the tool was adapted to take all
`option`s into consideration instead of only the direct children of the
`select`.
- because the `option` text is dynamically created from the date of the
test execution, the tool was adapted to allow targeting an `option`
based on its index by specifying the tour step's `run` as
`'text index N'`, `N` being the index of the `option`.

Steps to reproduce:
- Enable the sidebar of the `/blog` page.
- Select a month in the sidebar.
- Type something in the search box.

=> Did show an error popup while obtaining the autocompletion records.

[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986



task-3213916

closes odoo/odoo#114229

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

Steps to reproduce:
- create an attribute with "never" as the mode of creation;
- create a product with this attribute;
- add an optional products to this product;
- go to ecommerce and add this product to the cart;
- take care to change the value of the attribute;
- click on the "Proceed to Checkout" button.

Note: optional product allows to open the modal window on the ecommerce

Issue:
In the cart, the selected attributes are the default ones.

Cause:
We will look for the information in the modal window template.
Unfortunately, the `getCustomVariantValues` and `getNoVariantAttributeValues`
functions are not adapted to the modal window template.
Therefore, the information is not found.

Solution:
As the information is searched on the template of the modal window,
it is necessary to maintain the information on it.

opw-3140859

closes odoo/odoo#113763

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").

closes odoo/odoo#114549

X-original-commit: 713a46cd
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>

When using the 'Show on mobile' option, we can see that there is a
mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> under 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding an element in
the mobile view (for example, if it does not look good in it) has no
effect until the screen reaches 768px.

This commit increases the screen breakpoint at which the 'Show on
mobile' option is applied, that is, up to 992px instead of 768px, in
order to be consistent with the display.

task-3110770

closes odoo/odoo#114492

X-original-commit: 791670db
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

To generate an e-faktur

1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’

2. Accounting > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government)

3. Accounting > Configuration > Settings
- Fiscal Localization: select the Indonesian package

4. Accounting > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Fill Tax Address field
- Fill NIK field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
  Payable)
- Create a delivery address

5. Accounting > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur

Under column ALAMAT LENGKAP the tax Address will be used, but the
delivery address should be used
Follows the official documentation with translation
https://www.pajakku.com/tax-guide/12490/PER_DIRJEN_PJK/PER

 - 03/PJ/2022
(Article 6, paragraph 6)

Translation:
Paragraph 2 : The identity of the Buyer of Taxable Goods and Services or
the Recipient of Taxable Goods and Services which includes name,
address, NPWP, NIK, and passport number as referred to in Article 5
letter b must be filled in accordance with the actual or actual name,
address, NPWP, NIK, and passport number.

Paragraph 6 : In the event that the delivery of Taxable Goods and/or
Taxable Service is made to the Buyer of Taxable Goods and/or Receiver of
Taxable Service which is the place where the VAT or VAT and STLG payable
is concentrated, but the Taxable Goods and/or Taxable Service is sent or
delivered to the place where the VAT or VAT and STLG payable is
centralized, the following provisions shall apply:
a. the name and NPWP as referred to in paragraph (2) shall be the name
and NPWP of PKP where the VAT or VAT and STLG payable is centralized;
and

b. the address as referred to in paragraph (2) shall be the address of
the place where the VAT or VAT and STLG payable that is centralized
receives the Taxable Goods and/or Services.

opw-2878096

closes odoo/odoo#114048

X-original-commit: df74fb68
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Steps to reproduce the bug:
- Add multiple images on a product page
- Go to the shop and edit an image of this product by double clicking
on a small image on the carousel thumbnail
- Save
-> Nothing happens and the image is not updated

The goal of this commit is to ensure that a field of type image is not
`readonly` before adding the `contenteditable` attribute to its image.

task-3122670

closes odoo/odoo#109465

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

An employee with time officer access right would receive the error "You
must be False's manager to approve this leave" even if they were manager
of all the employees.

Now the error message will list all the employee's the user is not
manager of, and it will properly check that the user is manager of all
of them.

task-3220920

closes odoo/odoo#114542

Signed-off-by: Kevin Baptiste <kba@odoo.com>

The method update_state is called from cron. When the contracts are
updated couple things are checked. There are constraints set that can
throw ValidationError. As a result, none of the contract states are updated.

In this PR we do the following:
In case the ValidationError occurs when we run the cron, we update
contracts that can be updated, and silently pass the invalid contracts.

task - 3069480

bloupbloup

closes odoo/odoo#114287

X-original-commit: 66ba7a1b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>

If an user tries sending a invoice using an invoice address and a
delivery address through snailmail, it would result in a traceback.
This is due to the invoice address record not having a name.

closes odoo/odoo#114171

X-original-commit: eceb23b1
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

__Description of the issue this PR addresses:__
The first character of a Tax ID from Albania is a letter representing the decade in which it has been issued. The letter M represents the current decade. (This pdf explains in details how it is formated: https://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/Albania-TIN.pdf).

Currently the way Albanian Tax IDs are validated is through the python library [`python-stdnum`](https://pypi.org/project/python-stdnum/).
However, the regex that is used to validate them has not been updated since 2017. (I made a PR in its repo https://github.com/arthurdejong/python-stdnum/pull/402

 to fix that).

The code from this commit is inspired by the one from that library, but the regex includes the letter M.

__Current behavior before PR:__
(`base_vat` must be installed)
By going to Settings > Users & Companies > [A company]:
- Set the country to Albania
- Set VAT/Tax ID to “M12345678T”.

=> Error message

closes odoo/odoo#114438

X-original-commit: f0b6e4cc
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Steps to reproduce:

  - Install "Sales" module (for test purpose)
  - Change company name to `בונז " ור מונד` (notice the double quotes)
  - Go to "Settings > Users & Companies > Users"
  - Select any user and then click on "send an invitation email" button
  - Go to inbox and check the email

Issue:

  No email received (at least not in main inbox).

Cause:

  The email is not received in main inbox (Gmail or Outlook might flag
  them since email from is not well parsed) because the `email from`
  value is not escaped properly (by escaping the double quotes).

Solution:

  Instead of using the company name (that is not escaped) and email to
  build the `email from` value, use the company email_formatted value
  instead (and fallback on user mail if not available).

opw-3097910

closes odoo/odoo#113901

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

Step to reproduce:

    Edit documents layout in general setting to add logo and background
    select multiple documents (more than 5) e.g. Inventory> delivery slips
    print all documents.

Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them

Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load

opw-2951594

closes odoo/odoo#114493

X-original-commit: ac2df93e
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Steps to reproduce:

  - Install `Contacts` module
  - Create 3 contacts with the same name
  - Archive one of the contacts
  - Go to list view
  - Edit search filter to display archived and non archived contacts
  - Select the 3 created contacts
  - Open `Action` menu and click on `Merge`

Issues:

  - Archived partner is set by default as destination partner.
  - Archived partner is not displayed in the list of partners to merge.

Cause:

  - The default destination partner set is the last record of the record
    set returned by `_get_ordered_partner` (where `Archived` partners
    are the last ones in the record set).
  - The field `partner_ids` does not allow archived records.

Solution:

  - Sort the partners to have the archived ones on top (since we took
    the last one).
  - Set `active_test` to False in the context of the partner_ids field.

opw-3205577

closes odoo/odoo#114484

X-original-commit: 8d0cec68
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Before this commit, whenever a peer had no selection in the editor, no
selection would appear to the other collaborators. It was therefore
visually impossible to know excaltly to how many people someone is
connected.

Now, we set the default selection to be in the first node of the
document.

Additionnaly, some selection were not displayed because the call to
`getClientRects` did not return any rect. By creating a deep range
through the use of `getDeepestPosition`, we ensure to retrieve the
selection rect.

task-3217719

closes odoo/odoo#114417

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

The comment that describe the
`missingSteps === -1 || !missingSteps.length` condition was wrong.

task-3217719

Part-of: odoo/odoo#114417

Before this commit, any history step received before the history is
fully synchronised (`historySyncFinished`), would not be processed.

As a fail safe, this commit adds a buffer that will be processed as
soon as the history synchronization is finished
(`historySyncFinished`).

task-3217719

Part-of: odoo/odoo#114417

In the method `isClientFirst`, if
`clientA.startTime === clientB.startTime` is true (which should happen
exceptionally), the code calling `localCompare` would fail as the
method name is `localeCompare`.

task-3217719

Part-of: odoo/odoo#114417

Before this commit, the mutation that add `data-last-history-step` was
added to the history. Without the collaboration, it would not be
problematic but when the collaboration is activated, that step is
broadcasted to the other peers but shouldn't as the mutation is
considered to be technical and should not be included into the
undo/redo mechanism.

task-3217719

Part-of: odoo/odoo#114417

Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check

Issue:
Error is raised

Cause:
As for https://github.com/odoo/odoo/pull/112832

 there is a second check in order to increment the check number

opw-3140973

closes odoo/odoo#114416

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

closes odoo/odoo#114173

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

Before this commit, we only support rgba(xxx,yyy,zzz,v.www)
Now we support also rgba(xxx, yyy, zzz, v.www)

How to reproduce:
Edit theme color secondary, chose a color with transparency.
Go to a 404 page and the pinky will be not loaded.

closes odoo/odoo#114418

Signed-off-by: Jérémy Kersten <jke@odoo.com>

Before this commit:

unable to remove blockquote and heading element if first element.

After this commit:

removed element on backspace even if first element.

Task- 3004556

closes odoo/odoo#108255

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

We have a lot of hits without any forum_origin which will raise an
error 500 because this parameter is required. But because this params is
not into the controller but received as a get parameter, it will match
the controller and return an error 500 instead of a beautiful 404.

Some controller like 'open_partner' redirect to this url without the
parameter forum_origin too, leading in a 500 in all cases.

Better for uX to have this param, but not critical to display the page.
The only negative impact will be to have a 'Back' button that return to
this new default value '/forum'.

closes odoo/odoo#114419

Signed-off-by: Jérémy Kersten <jke@odoo.com>

To reproduce the issue:
(Also need: account_accountant,purchase)
1. Setup a product P
   - Storable
   - Category:
     - FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $50
4. Create and confirm a SO with 1 x P
    - Because of FIFO, the value of the delivered product is $10
5. Process the delivery
6. Post the invoice
7. Add credit note
   - Credit Method: Full refund and new draft invoice
8. Post the second invoice

Error: The cogs are based on the second received product ($50), they
should rather be based on the delivered one

When computing the anglo-saxon unit price of the product, we consume
the outgoing SVLs, and we consider the already-invoiced quantity.
Here is the issue: we pretend that this quantity is 1, because of
the first invoice, but this should be balanced with the quantity of
the credit note

OPW-3109789

closes odoo/odoo#114346

X-original-commit: d8e286ad
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

The BuyerReference (BT-10) should be easily editable by the user, so it is read
from the `commercial_partner_id.ref`.

The OrderReference (BT-13) should also be editable by the user, it is read from
the `move.ref`.

The definition for both tags in the peppol doc defines these tags as:
"An identifier assigned by the Buyer used for internal routing
purposes".

The new tag SalesOrderId (BT-14) is added, and is the sale order's name
linked to the invoice.

opw-3175906

closes odoo/odoo#114339

X-original-commit: https://github.com/odoo/odoo/commit/79f46cdba23715203ed218a36664d30927e45e7a


Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>