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

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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#113079

Signed-off-by: Josse Colpaert <jco@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#114614

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

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

To reproduce the issue:
1. Create an RFQ
2. Send it by email
3. Open link in email in incognito
4. URL in mail redirects to a login page

Error: Should be able to see the RFQ without being logged in

Backport of https://github.com/odoo/odoo/pull/87520/commits/c4bd3f450c571da1322acb464f837612d498647c
Which is a backport of https://github.com/odoo/odoo/commit/139e90027686b0471c3f2c9efa46d531c3abef5a


OPW-3175464

closes odoo/odoo#114541

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

1. Install CRM, Dashboards as admin
2. On Settings, enable Google Spreadsheet
3. Click on Dashboard, Google Spreadsheet
- key in data with actual URL
4. Log out and log back in as Marc Demo
- you cannot access Google Spreadsheet in Dashboard

Desired: enable the menu for partial visibility

opw-3055142

closes odoo/odoo#114152

Signed-off-by: Nicolas Lempereur (nle) <nle@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#112807

Signed-off-by: Merel Geens <mege@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#112901

Signed-off-by: Vincent Schippefilt (vsc) <vsc@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#114159

X-original-commit: eceb23b1
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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#114326

Signed-off-by: Adrien Widart <awt@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#110238

Signed-off-by: Outagant Mehdi (mou) <mou@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#113560

Signed-off-by: Julien Castiaux (juc) <juc@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#109053

Signed-off-by: Benoit Socias (bso) <bso@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#113778

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.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#114006

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

Fixing typo in
df74fb68

closes odoo/odoo#114412

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

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

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

Add a test that check recipients displayed in the template preview. This test
has been added following the fix that solves the template "partner_to" not
displayed in the preview.

Task-3196081

closes odoo/odoo#113341

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

To reproduce the problem (example):
- install the project app with demo data
- activate the debug mode
- go to Settings -> Technical -> Templates
- choose the template "Task: Rating Request"
- in email configuration, "To (partners)" is set to
${object.rating_get_partner_id().id}
- click on preview
- choose the task: "Room 2: Decoration"
- the "Recipients" field value should be "YourCompany, Joel Willis" but this
field remains empty without the fix

Technical note: partner_to of the template was not rendered which was making
generate_recipients returning incorrect values for partner_ids.

Task-3196081

Part-of: odoo/odoo#113341

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

Signed-off-by: William Henrotin (whe) <whe@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#114291

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

This commit fixes two bugs with the table of content snippet:

- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.

- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.

opw-3115597

closes odoo/odoo#109927

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

Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.

The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.

Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.

opw-3133464

closes odoo/odoo#113117

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

Prior to this commit, the height of the Image Gallery snippet was set to
auto on screens smaller than 400px.

This ensures that the snippet looks the best on phones.

However, when using Bootstrap, what defines a smaller screen is not
any screen below 400px, but any screen below 768px.
This meant that the Image Gallery snippet did not look the same on an
iPhone 11 Pro max as it would on an iPhone 11 for example.

This commit fixes that by using the built-in mixin that relies on
Bootstrap's breakpoints (in this case SM).

Steps to reproduce:
- Go in edit mode and drop an "Image Gallery" snippet
- Open the dev tools and choose "iPhone 11" or 375x812
- The image gallery does not have white bands
- Change the resolution to "iPhone 11 Pro Max" or 414x896
- The image gallery has white bands / has a different layout

opw-2995100
task-2997119

closes odoo/odoo#109761

Signed-off-by: Vray Benjamin (bvr) <bvr@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#113166

Signed-off-by: William Henrotin (whe) <whe@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#110941

Related: odoo/enterprise#36771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This commit fixes an issue with the width of items in the we-list not
being correct when they are being dragged using jQuery's sortable
feature.

Steps to reproduce the bug:

- Drop a "Form" snippet on a page.
- Add a "Multiple Checkboxes" field in the form.
- Move an option from the list using the move button.
- Bug: while dragging the item, the width of the items is too small.

When an element is dragged, it is given an absolute position which takes
it out of the normal flow of the document, causing the input element
within the list item to no longer be able to correctly occupy 100% of
the available width.

task-3138662

closes odoo/odoo#110871

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

For the moment, the price unit of the down payment line on the sale
order is not always correctly computed. If the price unit is updated on
the down payment invoice, it is not updated on the sale order; or if a
regular invoice is created, the price unit of the down payment is set to
zero on the sale order.

This commit corrects the behavior by using the unit price of the invoice
line.

opw-3140740
opw-3160406
opw-3160420

closes odoo/odoo#113769

Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>

To reproduce
============
- on accounting -> Vendor -> Bills
- upload the PDF attached on the ticket
an exception is raised

Problem
=======
PyPDF2 finds that this pdf is encrypted,so we try to decrypt it with empty password,
but the decryption fails which rise an error.

Solution
========
according to this [commit](https://github.com/odoo/odoo/commit/851fe64f7789bb398383c22e3ebbaebb051791f6

), when the decryption fails
we skip reading the attachments and carry on to allow the user to upload the document.

opw-3196780

closes odoo/odoo#114050

Signed-off-by: William André (wan) <wan@odoo.com>

OPW-3115528

closes odoo/odoo#108072

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

To reproduce the issue:
1. Create a product:
   - Type: Storable
   - Category:
     - Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product

Error: the total value is $-6.00, it should be zero

Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200



Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.

Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.

OPW-3101374

Part-of: odoo/odoo#108072
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>

If the IBAN includes a non-ASCII alphanumeric character and has just the right length, the IBAN validation crashes with a KeyError before validation can take place.

Fictional example: The supposed IBAN code "Bank München-Wiesn GmbH" gets normalized to "BankMünchenWiesnGmbH"; a string that starts with a valid country code ('BA', ie. Bosnia-Herzegovina) and happens to have the same length as Bosnia-Herzegovina's IBAN format (20 characters). Normally this erroneous IBAN would've been rejected as invalid, but Python throws a KeyError when trying to convert 'ü' to an int right before the validation step.

We therefore need to also check if all characters in the IBAN code are within the expected range, namely [a-zA-Z0-9] (strictly speaking, the IBAN's specification range is only [A-Z0-9], but we can be lenient since Python's `int()` is case-insensitive).

closes odoo/odoo#113719

X-original-commit: fc468f5a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Elias <elre@odoo.com>

Steps to reproduce:
- create a sale order;
- add products which are based on timesheets for invoicing policy;
- create an invoice an confirm it;
- make a full refund for this invoice with "ADD CREDIT NOTE" button;
- create an new invoice for the sale order.

Issue:
There is no longer a statistics button
that displays the hours worked on the invoice view.

Cause:
To reassign an account move to an account analytic line,
it is necessary either that there is no invoice
or that the invoice is in the cancel state.
The case where the invoice has been refunded is not taken into account.

Solution:
Correct the domain that determines the timesheets (account analytic line)
to be linked with the invoice being created.

opw-3187219

closes odoo/odoo#113985

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

To reproduce
============
- with Invoicing installed, give a user the group Billing Administrator without giving any Administration group
- connect to this user and try to add a bank account
an access right is raised

Problem
=======
the `groups_id` on the action `action_new_bank_setting` is not specified
so when runing the action we check if it has `groups_id`, if not, we check
if the user has the right to write on the target model which is `res.company`
here, which is not for this user because he doesn't have any Administration group.

Solution
========
specify `groups_id` to `account.group_account_manager`

opw-3199435

closes odoo/odoo#113836

Signed-off-by: William André (wan) <wan@odoo.com>

backward port of:
https://github.com/odoo/odoo/pull/113768

Before this commit:
 If a payulatam payment is received from the confirmation
 page (so, with the webhook). If the value have some decimals
 it might be rounded in the wrong way.
 As such, the generated signature to compare with is wrong
 and the payment validation cancelled

After this commit
 If we cross compare the signature generation documentation:
 https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/response-page.html#signature-validation
 https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/confirmation-page.html#signature-validation


 We notice that the `new_value` computation is slightly different
 depending on the return.
 The one we currently use for both method is the "return"
 one which is computed differently from the "confirm" one.

 With this change of code a "confirmation" page payment
 will be validated as intended.

I also changed the log level from warning to exception
so that the traceback and exception message is logged.
Before this commit there was just a generic warning message

opw-3018628

closes odoo/odoo#113987

X-original-commit: 0e29f948
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@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#94338

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

Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.

Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series

=> The matrix overflows from the editor.

There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.

As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.

task-3094162

closes odoo/odoo#107400

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

With DB having only one blog (most common case, but we are used to test
it with demo data where we have two), the query params are lost when
accessing the blog controller without passing a blog.

Eg, `/blog?search=hubble` will redirect to `/blog/traval-1`

This is because the business code is doing an early redirect if we
access the `/blog` URL without a blog post passed to it to redirect to
that blog post URL directly (since there is only one), but that redirect
is not passing the query parameters.

The main impacted params are `state`, `order` and `search` but it's the
same for all others.

Step to reproduce (in later version):
- Be sure to only have one blog
- Drag & drop the search snippet in the homepage or anywhere
- Make it search on blog only (through the snippet option)

Type anything, it will not work and won't do the search. It will just
redirect to the blog page.

closes odoo/odoo#113855

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

Before this commit, the user had the possibility to spam the "Log in"
button when trying to connect. This could lead to a change of the CSFR
token and an errror of type "werkzeug.exceptions.BadRequest: 400 Bad
Request: Session expired (invalid CSRF token)" could then happen.
This commit makes the “Log in” button un-clickable once it has been
clicked and adds a loading effect to it.

task-2996329

closes odoo/odoo#104323

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