closes odoo/odoo#99588

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

Returning after first loop iteration has the sad side effect of
somehow breaking batch version of methods.

Oversight of odoo/odoo@0ea27f430c27716e9f995523f050ba70fa4befde

closes odoo/odoo#99574

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

Before this commit, the dialog 'View Metadata' open the date in utc
since the refactoring of Owl. It is not coherent with all others dates
shown in form.

Now we show the date in the timezone of the current user.

Partial backport of #92108

closes odoo/odoo#99570

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

Steps to reproduce:
- Create Accrual plan to add 3 days with frequency Yearly on 1 of
January and days lost at the end of the year
- Submit an Allocation request for this accrual plan starting more than
2 years ago
- Run scheduled action "Accrual Time: Updates the number of time off"

Current behavior:
Allocation request calculation time off computes 0 hours

Expected behavior:
Allocation request calculation time off computes 3 hours for the
period between the first of last year and the first of this year

Explanation:
With this modification there are two changes:

1) When the attribution day is the first of january, the nextcall
set in the _end_of_the_year_accrual is the first day of next
year meaning that no days are going to be computed for the last
year period. We change that so that if the first of the year is
the attribution day then the first of the year is the nextcall and
the last call is computed accordingly.

2) If the period to compute the attributed days is acrros two years
the begining of the period is not the first of the year anymore but
the usual lastcall, this has an impact particularly on based on
worked time accrual plans.

opw-2948216

closes odoo/odoo#99016

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

Go to Project -> Reporting -> Timesheets and Planning Analysis and
select other measures in the pivot view via the "Measures" menu.
After that create a new favorite.

Result: the favorite is saved with the correct measures but the
pivot view will never use those measures. This is due to the presence
of the key "pivot_measures" in the action context.

(Note that the same problems occurs with other keys and other views)

We fix that problem by giving less precedence to keys in action contexts
with respect to those found in the search item contexts as it was
originaly the case in legacy views (cfr. __get method in action_model.js).

opw-2945969

closes odoo/odoo#99557

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Steps to reproduce:

  - Install Inventory
  - Open any product
  - Switch to RTL language
  - Edit the product
  - Try to translate field "Internal Note"

Issue:

  Button is not displayed correctly (nearly hidden).
  Issue also present with wysiwyg or codeview editors.

Cause:

  Applying style `right: 5px` to the button without taking into account
  if layout direction.

Solution:

  On translate button:
  - Apply direction left for side-space if RTL, else right.
  - If wysiwyg is enabled, add it after the buttons in the sidebar.

opw-2962790

closes odoo/odoo#98963

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

When we create a pdf preview in the mail generation (from a quotation), on
Firefox the promise doesn't get resolved (the server response is 200), it
may have something to do with the transition from legacy JS -> Owl.
This patch is providing a workaround by opening the links in a new tab,
those tabs are automatically closed by themselves and solves the issue/doesn't
alter the UX.

Affected versions:
- 15.0
- 15.2

opw-2964376

closes odoo/odoo#99341

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Steps to reproduce:

  - Install purchase
  - Go to Settings and activate `Variant Grid Entry`
  - Create a new Requests for Quotation
  - Add a customer and add a product that has a variant min 2 variant
  - Wizard should ask for the variant
  - Select 1 variant by increasing quantity in the grid and confirm
  - Confirm order
  - Add again a product variant with the wizard

Issue:

  Price unit is not set on the new line.

Cause:

  In `_onchange_quantity` (triggered by the purchase_product_matrix
  module), we do not update price unit if order line
  is in state `purchase` or `done`.

Solution:

  Replace condition to not perform `_onchange_quantity` if order line
  has an invoice line.

opw-2956755

closes odoo/odoo#99519

X-original-commit: a5632601
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Steps to reproduce:

  - Install pos_sale module
  - Create a product and set it as available in POS
  - Create 2 variants and set a weight for each variant
  - Open a POS session and make an order with one of the variants
  - Go to the Sales -> Reporting -> Sales and select view pivot
  - Set Gross Weight as measure

Issue:

  Weight for ordered variant is set to 0.

Cause:

  Sales Analysis is an SQL view and it use product template in instead
  of product product to get the weight value.

opw-2956457

closes odoo/odoo#99500

X-original-commit: 3d5e2764
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Avoid duplicated entry

closes odoo/odoo#99509

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

In Firefox only :
In some case (editor in page but not visible) the
`document.getSelection` sometimes return `null` instead
of an empty selection object. We add some check to ensure
we avoid unnecessary traceback.

task-2971126

closes odoo/odoo#99485

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

Since https://github.com/odoo/odoo/pull/96545

, the calculation of the leaves
taken was done the same way between a holiday type that requires an allocation or
one that doesn't.

This commit fixes the number of days calculation for a holiday type that doesn't require an allocation.

task-2969687

closes odoo/odoo#99449

Signed-off-by: phwa-odoo <phwa@odoo.com>

The document type definition was loaded too late
This resulted in missing references in AccountChartTemplate's method
_get_demo_data_move

Changing the order fixes the missing references

closes odoo/odoo#99413

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

The cost (purchase_price) of a sale order line is recomputed when the
sale order is confirmed, overwriting the potentially edited value

Steps to reproduce:
1. Install sale_stock_margin module
2. Create a quotation, add any customer and two lines: a service (e.g.
   Deposit) and any other storable product (e.g. Large Cabinet)
3. Activate 'Cost (purchase_price)' column in the order lines view
4. Edit the cost of Deposit and confirm the quotation
5. The cost resets to the original product cost

Solution:
Modify the dependency of `_compute_purchase_price` to trigger it only
when the sale order line's related picking has changed state

Problem:
The dependency on order_id.picking_ids.state makes it that the purchase
price is recomputed for all sale order lines when any of the picking of
the related sale order has a modified state (but we want to recompute it
only for the sale order line that had its picking's state modified)

opw-2904500

closes odoo/odoo#99435

X-original-commit: 9947b617
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Tax Report _compute_from_amls_grids query calls
two method overriden in pos_account_reports.

The resulting query contains EXISTS subqueries on pos_session.move_id
and pos_order.account_move. Because these two fields are not indexed
by default, the cost of the query can skyrocket in large databases,
leading to slow tax report generation.

closes odoo/odoo#99077

X-original-commit: 51e607a7
Signed-off-by: Rémy Voet <ryv@odoo.com>

task-2884212

closes odoo/odoo#99390

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

- Before this commit
formatDate would, under certain circumstances, take into
account the timezone offset of the input value

- After this commit
It won't anymore

closes odoo/odoo#99327

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

On non-legacy views (like Pivot) the vertical alignement of the
searchbar wasn't properly centered. Also there wasn't enough spacing
between the actual search input and the bottom line.

This commit fixes it by certically center it and normalize the bottom
padding accross legacy/non-legacy and mobile/desktop.

closes odoo/odoo#99284

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Definition of reconciled line was recently changed [1] and draft records are not
marked as reconciled anymore. However POS session closing still needs old
definition of reconciled line, because state of the related journal entry is
still draft and hence `reconciled` value is always equal to `False`.

STEPS

1. POS -> Open Session -> Order -> Invoiced
2. Backend -> Open Order - Return Products -> Payment -> Invoiced
3. Close session

BEFORE: error *You are trying to reconcile some entries that are already reconciled.*
AFTER: POS Session is closed successfully

But previous commit fixed it. This commit only adds a test.

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



opw-2859747

closes odoo/odoo#98520

X-original-commit: aa734091
Related: odoo/enterprise#30930
Signed-off-by: William André (wan) <wan@odoo.com>

Fine-tuning of https://github.com/odoo/odoo/commit/c8c3aa96e18827c3c032540b92e95b27bbed0fc3.

Also, in _prepare_reconciliation_partials, consider case of having aml without credit, debit and amount_currency.

X-original-commit: 653d84e4
Part-of: odoo/odoo#98520

[FIX] account_facturx, account_edi_ubl_cii, l10n_account_edi_ubl_cii_tests: add partner email to factur_x XML

Currently, when creating an invoice from factur_x XML, the vendor is
identified by sequentially checking (in this order) the following
information :
- VAT number
- name
- email
However, when we generate a factur_x XML, we do not include
the partner's email address. This means that in some cases, two odoo
databases are not able to communicate bills/invoices properly.
This commit brings back a behavior that was unintentionally removed in
d25fdafc

opw-2909408

closes odoo/odoo#99249

X-original-commit: 51609d19
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>

Before this commit:

changing header style, changes the alignment of the selection

After this commit:

Now after applying header on selection it doesnot changes its alignment.

Task-2641462

closes odoo/odoo#94384

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

Reproduction:
1. Install Timesheet, and load demo data
2. Mimic a timezone in browser (Chrome): Right click->Inspect->Sensors,
in the Location-> choose Other…, type “America/Puerto_Rico” in Timezone
ID, refresh the page
3. Go to Timesheets->Timesheets->All timesheets, choose pivot view
4. Add custom filter, Date is between 1st/Aug/2022 and 5th/Aug/2022,
apply
5. The filter result is correct but the tag in the search bar is “Date
is between 31/07/2022 and 04/08/2022”

This also happens to other fields with type Date, but not Datetime. For
example, in Accounting->Reporting->Invoices Analysis->Pivot view, the
same issue happens with Due Date filter. For Datetime field, it doesn’t
have the issue, for example in CRM->Sales->My pipeline, change to pivot
view, the custom filter for Assignment Date doesn’t have the time zone
issue.

Note: reproduction usually works during the daytime in Brussels.

Reason: miswriting when rewrote custom_filter_item from V14 to V15. The
value pushed to descriptionArray should not be changed on time zone.

Fix: add type check for Date and Datetime in parseField and formatField.
When it’s Datetime, with timezone converting. When it’s a Date, no
timezone converting. Add test for the Date filters

Related PR: https://github.com/odoo-dev/odoo/commit/aeb8e49972f871b0c9b07c507987ee77cf5e8abd?diff=unified#diff-6d9230cfcd007b087b2851cbf0b4a33b26dc3c91087853da6fe7ce8c2b60e42f

Reference code in V14: https://github.com/odoo/odoo/blob/14.0/addons/web/static/src/js/control_panel/custom_filter_item.js#L170-L173



opw-2941231

closes odoo/odoo#98413

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

The dropdown is positionned from the left, with comming from bootstrap:

- left: 0; # from CSS [OVERRIDEN]
- right: auto; # from CSS
- left: 0px; # from JS
- transform: translate3d(123px, 0px, 0px); # from JS

the 123 pixels is the offset to the left border of the parent component.

This is working in left-to-right, but in right-to-left, only the CSS
style is reversed and we get:

- right: 0; # from CSS
- left: auto; # from CSS [OVERRIDEN]
- left: 0px;
- transform: translate3d(123px, 0px, 0px);

Since the result is `right: 0; left: 0px` the size of the dropdown is
set to 100%, but this is not taken into account by Popper.computeStyle
which will have a 100% parent width Popper set at the position of the
small width Popper.

Graphical example:

```
[----------------------] # width of the page
[---]                    # popper in LTR
                   [---] # popper in RTL with fix
         [-------------] # popper parent size
                   [-------------] # popper in RTL without fix
```

as shown, without the fix, the popper content might overflow outside of
the page, and the content aligned to the right unseen).

opw-2926863

closes odoo/odoo#98278

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

This commit makes FCE Is Cancellation Field inivible in non Argentinean Companies

closes odoo/odoo#99265

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

Before this commit:

Conversion of list element to paragraph block was not possible, as Text from
command-list was only changing the tag of a selected element, not the list tag.

After this commit:

Now list element can be converted to a paragraph block when the Text block is
selected.

Task-2826472

closes odoo/odoo#94429

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

Before this commit, Chatter in project sharing: the
'employees only' and 'visible' buttons are not toggled and both
are visible at same time.

So in this commit fixes the issue by making the 'employee only'
and 'visible' button as toggle button same as portal chatter.

task-2858336

closes odoo/odoo#94116

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Non total order can lead to randomized order in some case, making some
test behaviour random and/or difficult to debug.

Adding some fallback 'id' order shouldn't hurt

closes odoo/odoo#91911

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

Before this commit:
===================
GST Treatment(l10n_in_gst_treatment) is not when create invoice from POS.

After this commit:
==================
GST Treatment(l10n_in_gst_treatment) is set when create invoice from POS.

closes odoo/odoo#99243

X-original-commit: a46f3a4a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Jigar Vaghela (jva) <jva@odoo.com>

The constraint can crash if the zip is not defined.
Check that the zip exists to prevent the error.

closes odoo/odoo#99226

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

Orders in POS all use the same fiscal position (the fiscal position
currently selected in the POS) so their tax might be wrong if the order
used another fiscal position that applies another tax mapping

Steps to reproduce:
1. Install Point of Sale
2. Go to Invoicing > Configuration > Accounting > Fiscal Positions and
   create a fiscal position 'Test' with a tax mapping from 'Tax 15.00%
   (Sales)' to 'Tax 10.00% (Sales)' (that you should create)
3. Go to Point of Sale and edit 'Shop' settings
4. Enable 'Manage Orders' and 'Fiscal Position per Order' and add fiscal
   position 'Test'
5. Go to Products and add 'Tax 15.00%' to the Customer Taxes of product
   'Acoustic Bloc Screens'
6. Open a new session in POS 'Shop'
7. Add 'Acoustic Bloc Screens' to the order with fiscal position 'Test'
   and validate it (total is $3,245.00)
8. Click on 'New Order' and then on the order management button
   (magnifying glass in the top right)
9. The order total is $3,392.50, if you go back and select the fiscal
   position 'Test', the order will have the correct total in the order
   management screen

Solution:
When we compute the taxes of an order, apply the tax mapping of the
fiscal position used on the order

Problem:
The taxes applied on the orders are all computed with the fiscal
position of the POS

opw-2956608

closes odoo/odoo#99236

X-original-commit: 30ca2849
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Before this commit, when the portal user changes the stage of a task and
the new stage contains a rating template email, he got a traceback
saying he has no access to `mail.template` model.

This commit fixes the issue by sending the email in superuser when we
are sure the user can write on that task.

Steps to reproduce:
==================

1) Enable the rating feature in the settings of Project App
2) Create a Project A and edit it to enable the rating feature on that
project and select "Rating when changing stage" (if it is not already
the case)
3) Set a rating email template on a stage of the project
4) Create a new task and save
5) Change the stage of that task to the stage contained the rating email
template

Actual Behavior:
---------------
A traceback is occurred saying the user has no access to `mail.template`
model.

Expected Behavior:
-----------------
The stage of the task should be changed and the rating email should be
sent.

closes odoo/odoo#99215

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

**Template Access Issue**

Followup of odoo/odoo@1a3e713c99474951cb5000c55a2382ba12074273

Bug
===

If the user doesn't have the template editor, he cannot open the template
preview.

Technical
=========

The reason for that is because the web editor moves some CSS properties,
and so when the user tries to open the preview, an access error is raised.

1. Ideally, the template form view should not be editable if the access
rules do not allow it. But in `_postprocess_tag_field`, we only check
for access right because we don't have the record. So a user without
write access rules, but having write access right can edit the template
in the UI, and gets an error when saving.

2. Also, the web editor should not save the HTML value if no change are
made on the field (like all other text / char field).

To mitigate the issue in stable, we add a computed field that check the
access rules and make the body readonly if he can not edit the template.
So the web editor is not loaded, the CSS properties are not moved. Other
possible solutions are way to complex technically speaking (editor internals
to update in frontend, complex comparison of html blobs in backend, cache
usage making fields_view_get override not working in all cases, ... )

As the HTML body look weird in readonly mode, add the same border as the web
editor.

**Ir.Model Issue**

A user without administration right can not preview a mail template because
of the ACl on the <ir.model>.

Task-2845877

closes odoo/odoo#94418

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

Bug
===
A user without administration right can not preview a mail template because
of the ACl on the <ir.model>.

Task-2845877

Part-of: odoo/odoo#94418

Followup of odoo/odoo@1a3e713

Bug
===
If the user doesn't have the template editor, he cannot open the template
preview.

Technical
=========
The reason for that is because the web editor moves some CSS properties,
and so when the user tries to open the preview, an access error is raised.

Ideally, the template form view should not be editable if the access
rules do not allow it. But in _postprocess_tag_field, we only check
for access right because we don't have the record. So a user without
write access rules, but having write access right can edit the template
in the UI, and gets an error when saving.

Also, the web editor should not save the HTML value if no change are
made on the field (like all other text / char field).

To mitigate the issue in stable, we add a computed field that check the
access rules and make the body readonly if he can not edit the template.
So the web editor is not loaded, the CSS properties are not moved. Other
possible solutions are way to complex technically speaking (editor internals
to update in frontend, complex comparison of html blobs in backend, cache
usage making fields_view_get override not working in all cases, ... )

As the HTML body look weird in readonly mode, add the same border as the web
editor.

Task-2845877

Part-of: odoo/odoo#94418

Reproduction:
1. Install Timesheet, and Project, check the timesheet box in the
setting of Project
2. Go to Setting->manage users, set access right for Marc Demo, Project
as “User”, Timesheets as “See own timesheets”, and Helpdesk	as “User”
3. Go to Project, create a task and assign it to Marc Demo, go to the
timesheet tab, set Initially Planned Hours as 20 hours, click save
4. Open an incognito page and log in as Marc Demo, go to this new task->
timesheet, edit, log 5 hours, save. Hour spent is now 5
5. Switch back to Mitchell Admin, refresh the task page, edit, log 3
hours, save. Hour spent is now 8.
6. Switch to the incognito page of Marc Demo, edit, log 2 hours and save
Hour spent is now 7, which doesn’t consider the hours logged by Mitchell
The right result should be 10 hours.
7. Switch back as Mitchell Demo, the spent hours are also wrong

Reason: The cause is that effective_hours is a stored computed field.
When Marc Demo logs hours after Mithcell Admin, the hours from Mitchell
do not show for Marc Demo. Marc Demo cannot get the hours from other
users because he can only see his own timesheet. Thus the computation is
wrong and because it’s a stored computed field, it won’t change even
after switching back to Mitchell Admin

Fix: Use read_group to get the grouped by value of the amount spent on
the task. This makes sure that the value of Hours spent is correctly
computed after saving. It also allows the onchange to take the change
made by the user into account before saving.

opw-2909444

closes odoo/odoo#99186

X-original-commit: 2033f113
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>

Before this commit, in invoice/bill, when changing
the account of a tax line while having one of the invoice
lines with tax 0%, the tax line was not displayed anymore.

The cause of the issue is that in _recompute_dynamic_lines
method, when setting the tax repartition lines to
recompute, we did not filter the 0 tax. The consequence was
that we had a delta between expected and current taxes,
although the line of tax 0% was not displayed anyway.
By filtering the 0 tax, we have expected taxes == current taxes,
so we do not have delta anymore, therefore no tax line to recompute.

opw-2901833

closes odoo/odoo#99085

X-original-commit: adf34254
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

Steps to reproduce the bug:
- install eCommerce module with assets
- go to any product page
- check the source code with https://validator.schema.org/

Notice that the 'image' and 'url' microdata tags have no base url,
so the engine assumes http://schema.org/

 to be the base url. This
makes certain ad trackers such as facebook pixel unable to detect
the product being sold.

This commit adds the base_url field to both tags so that they are
correctly traced.

opw-2830058

closes odoo/odoo#99161

X-original-commit: daeba1a5
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Since the accounts without token are useless and could create errors
afterwards, we should delete them and automatically create a new one
with a new token in case force_create is set to True.

closes odoo/odoo#99125

X-original-commit: 637df81a
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>