Since the `account` module contains a CoA and is installed before any
other `l10n_` module, the condition `and not self.env.company.chart_template`
was always preventing the installation of a foreign CoA.
By delaying until the registry is fully loaded, we will take the last
CoA declared in the installation stack.
task-3256385
closesodoo/odoo#117944
Related: odoo/enterprise#39452
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
As the number of `account.move`, `account.move.line`,
`account.bank.statement.line` and `account.journal` is growing, the
accounting dashboard, which is the entry point of the app, gets slower
and slower.
There are multiple issues being addressed in this commit:
* The data for each journal is computed journal by journal. This means
that the number of queries run increases linearly with the number of
journals. While the boilerplate around running multiple queries is
negligible compared to the running time of the queries in this case,
some queries take as much time to run for one journal or for many.
To improve this, all the queries are now batched. This has been done
by refactoring the code; all these functions are now called on as many
records as needed[^1]:
- `_get_journal_bank_account_balance`
- `_get_journal_outstanding_payments_account_balance`
- `_get_last_bank_statement`
- `get_line_graph_datas`
- `get_bar_graph_datas`
- `get_journal_dashboard_datas`
* The gap detection and the entries' count are computed fields
(`has_sequence_holes` and `entries_count` respectively). We don't need
to display/compute these fields for all types of journals, but since
they were mentioned by using a `<field/>` node in the view, they were
computed for all journals displayed. Instead of using the `<field/>`
node, we are now setting the value in the `kanban_dashboard` field.
* Documents in foreign currencies on journals in foreign currencies need
to get the rate in order to be aggregated in the journal's currency.
There are 3 cases:
- Document in journal's currency
- Company's currency is the same as the journal's
- Document, company and journal have 3 different currencies
Before this commit, the second case will still fetch the daily rate
for the document in order to do the conversion, but we actually
already know the conversion; it is stored on the document.
Benchmark
=========
On a `populate` database with:
- 4 `res.company` (with accounting enabled)
- 45 `account.journal`
- 19k `account.move`
- 140k `account.move.line`
- 4k `account.bank.statement.line`
- 4 `account.bank.statement`
| Query count | Query time | Remaining time
--------------------------- | ----------- | ---------- | --------------
Before fix | 279 | 0.333s | 0.375s
After fix (without update) | 40 | 0.120s | 0.170s
After fix (with update[^2]) | 38 | 0.100s | 0.170s
Note that the currency conversion was disabled because the populate
database doesn't represent a realistic dataset regarding this. Disabling
it only improves the numbers before the fix.
Note
====
A lot of the time remaining comes from the aggregation of
draft/unpaid invoices with the correct rate done in python instead of in
SQL. This commit doesn't change the behavior but this could be rethought
from a function point of view.
________________________________________________________________________
[^1]: the old functions have been kept for compatibility, new ones are
suffixed by `_batched` and made private if it wasn't the case.
[^2]: some optimization require the views and indexes to be updated
closesodoo/odoo#117964
X-original-commit: 0a386932d2cbcb44cf36c1830422e52b285ae990
Related: odoo/enterprise#39461
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
`res.currency` already has some utilitises like `round` or
`compare_amounts` but until now we always needed to import
`format_amount` from the tools in order to format.
This commit unifies the API.
X-original-commit: 3517a0fece96dd5d0deb02c9fd973444e748986b
Part-of: odoo/odoo#117964
Recently the tax report was updated with new tax report lines, but translations weren't added.
This commit adds translations in FR, DE.
task-3264626
closesodoo/odoo#117962
X-original-commit: 35e5de512eb126bd9a4c7989c8e34c910abcd50f
Related: odoo/enterprise#39458
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit, even if customer rating is disabled from setting user can
get subscription of task rating.
This commit ensures that only when the customer rating field is enabled, the user can
get a subscription to task rating.
task-323170
closesodoo/odoo#117577
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
How to reproduce
================
1. Load the accounting & any of the modified l10n modules
2. Take any of the languages supported by the selected l10n module
You'll see that all the terms remain in english
opw-3114100
closesodoo/odoo#113572
X-original-commit: 13b619477977254d5cb070d716e0c07f87cb7407
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Happen since 29d55e44
To reproduce the error:
- Settings > Inventory > Enable "Product Packagings"
- Inventory > Configuration > Products > Product Packagings
- Create a new packaging having a barcode
- Start a Point of Sale session
- The session is not loaded and a traceback is raised
Reason:
we try to apply the find() method on an object instead of an array
After this commit, the session is loaded and the packaging is correctly
displayed
closesodoo/odoo#117947
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
project_profitability + change the name displayed in portal
This commit's purpose is to
- add the computation of the AAL for the project profitabity. If a the
analytic account of a project contains AAL that were manually added (
and thus not linked to any sol/purchase/etc ) those lines are not
computed in the 'other costs/other revenues section.
- to display the title of the ticket/task/project in the name of the page My ticket/My task/My project of the portal
task-2960753
closesodoo/odoo#106438
Related: odoo/enterprise#34344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
the error will occur because when you first add the menu that's menu can not
store in the database without clicking on the save button and that id is
temporary store in string format now you delete that menu and click on save they
try to browse that menu but it is not available in the database and also it has
a string.
steps to produce this error:
1) go to the website and click on 'menu editor'
2) click on 'Add Menu Item' button
3) Add name and URL and click on the ok button.
4) now delete the newly added menu and save it.
So here we can check the id type.
sentry-3931666290
closesodoo/odoo#117937
X-original-commit: 334e13a21dee6cba44aaa4ee79827278a89ab275
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since 5da90dfc4 a test has been added in which
a global readonly variable from `window`
is reassigned.
Furthermore, it is the global "parent" which is
read-only and should nerver be modified.
closesodoo/odoo#117927
X-original-commit: 169a471c7d48891d3295e2b597300425fb145abc
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Since 8fb53c53c3, Order model is no longer
a backbone model therefore, we can no longer call the "trigger" method
on it. Normally, the old "trigger" call means we want to rerender the
screen and persist the new order information in the local storage.
The order object is already setup to do those mentioned (rerendering
and saving to local storage) when it's mutated. Therefore, we can just
simply remove the "order.trigger" and "this.render" calls as proposed
in this commit.
closesodoo/odoo#117915
X-original-commit: 603d73ad8f181a4e5154153cad2cbb18a493b536
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit removes the onCreate param in Kanban, as it is no
longer useful since [1]. It also removes the beforeLoadProm param
and replaces it by an onWillStart option, which is slightly cleaner
(there was no reason for this to be a model param as it is only
used by the useModel hook).
[1] 067bcac533
Part of task 3179751
closesodoo/odoo#117889
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit improves the overlay icon that appears on call participant
cards when an error in the media players occur. The icon is now
clickable, which restarts an attempt to play all the `HTMLMediaElement`s
of the call as a recoverable error can occur when the browser does not
allow `HTMLMediaElement`s being played outside a user interaction.
other related changes:
* removing the `pointer-event:none` from the overlay as it was preventing
hover events, and the title tooltip from appearing.
* removing the try/catch around the `srcObject` assignment, as it should
only crash on old browsers without support for `srcObject` for which the
support of using the alternative (`URL.createObjectUrl` with
`src`) is being dropped.
closesodoo/odoo#117446
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Historically the point of sale hasn't had many unit tests as they are
difficult to write because the pos depends heavily on data. The
webclient also suffers from this problem and has created a lot of
infrastructure code that can be reused in the pos by simply implementing
a few routes in the mock server and loading the proper services during
the test. This commit adds a super basic test that just mounts the
chrome with mocked services and checks that it's there.
closesodoo/odoo#117290
Related: odoo/enterprise#39123
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: web
This commit removes the use of the legacy environment from the PoS, as
it is no longer needed. This will allow us to more easily use the new
unit testing infrastructure from web.
Part-of: odoo/odoo#117290
Previously, the customer display logic was split among multiple places:
the customer display button, the hardwareProxy service and the pos
global state. This commit extracts most of the logic to a new service
instead, and encapsulates the behaviour of a local display (popup
window) and a remote display (through an iot box) in separate classes.
Part-of: odoo/odoo#117290
Current behavior:
When you create a contact and a delivery adress for this contact. If you
add the delivery adress as a vendor to a product, and purchase this
product from the delivery adress, the contact will be added to the
product vendor list.
Steps to reproduce:
- Create contact C
- Create delivery adress D for C
- Create product P
- Add D as a vendor to P
- Create PO for P from D, and confirm it
- Go to P, and check the vendor list (C is there)
opw-3177309
closesodoo/odoo#117902
X-original-commit: 67031d2b3d7d52297d18a69c76b4f747b17142e3
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit adds a new prop to the Dropdown component: autoOpen.
It is true by default and follows the current behavior of all
current dropdowns (automatically open the dropdown when it is
hovered and a sibling is already opened) when set to true and
disable this feature for the dropdown when set to false.
The commit also applies this new property and set it to false on
all small icon dropdowns that are present by default in the
enterprise navbar to facilitate navigation with these (debug,
messaging and activity)
opw-3259473
closesodoo/odoo#117622
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit removes the manualOnly prop on the Dropdown component
and all its related code because it seems unused.
opw-3259473
Part-of: odoo/odoo#117622
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
Following the refactor done in [1], it is no longer possible to use the
`value` prop. Instead, the field should explicitly use
`props.record.data[props.name]`.
However, while [1] tried to adapt all the existing fields,
`website_publish_button` was forgotten.
This commit adapts website_publish_button.
Steps to reproduce:
- Install website_sale
- Go to the website app
- In the configuration menu select Shipping Methods
- Chose one of the shipping method
- Try to toggle the "Unpublished/Published" button
=> The value does not update properly
[1]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353
task-3223146
closesodoo/odoo#117833
X-original-commit: ddadbeed4700e537f7758746298fec43de997b21
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Steps:
- Install Project
- portal view > task
Issue:
- the private task was displayed in the portal view
Cause:
- the domain was not set for the private portal project
Fix:
- displayed task whose project_id is not false
- so private project was not displayed in the portal view
task-3147011
closesodoo/odoo#117783
X-orignal-commit: https://github.com/odoo/odoo/pull/111456/commits/2c00c7d37cf66601e7a25e22d6170973ea78b158
X-original-commit: b4ff1f0cd543fec9ca653fad97a96287e50743d7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commits makes the TagsList component able to display icons as well
as images were previously supported. A test has been added to verify the
presence of the icon set in each tag.
closesodoo/odoo#117751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project
This commit adds test to this component and removes unused props. Since commit (1),
it is now considered as a core component. Those props have been removed from the
props declaration, to better match the real usage of the component.
Since the className props was not present:
- The o_kanban_tag class given in theory were not set in practice. The rules
corresponding to that class were already adapted to fix the display of tags in the
kanban view. It was possible to get rid of the references to the o_kanban_tag class.
- The o_field_property_tag_readonly class was also missing, and the logic to prevent
the click on tags was duplicated in the onTagClick function. This makes the class
useless. I removed mentions to this classname. Instead, each tag has the pe-none class
using the same condition, but set in the tag declaration.
(1): 129fa3f150
Part-of: odoo/odoo#117751
steps:
project > kanban card > task analysis > list view of report
cause:
trying to open a project from the list view
issue:
looking for __count in read_group
fix:
add no_open to project_id in the list view because we can open a project from
kanban card and configuration
task-3111378
closesodoo/odoo#117773
X-original-commit: aa051ccf9566cb0eb74d6357de7f069165349e48
Related: odoo/enterprise#39360
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
By checking the script checking if all the account supposed to be in the BS are.
The account 1380 of skr03 and the account 9090 of skr04 seems to be miss
configured.
For the first account, we went back to task 31826 when the account was added.
And we think that the account 1380 was indeed misconfigured. For the other,
by comparing with skr03 which has the same account, we can see that the type
of the account is wrong.
Also, the balance sheet works with tags. Some accounts added after the load of
the chart template were missing some tags. By overriding those methods,
we can add tags afterward and be sure that those account are present in the
Balance sheet.
closesodoo/odoo#117881
Task-id: 3041738
X-original-commit: 44e8295b2df5db73efa7a85003332c092fbfca7b
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
When generating invoice for PoS orders, if a cash rounding is applied,
a cash rounding line is generated. Thus it is not possible to have
`rounding_applied` and NOT `rounding_line`.
closesodoo/odoo#114122
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
PaymentScreenTotalDueWithOverPayment result to random runbot error because the
test is performing a series of steps that clicks the validate button which will
randomly result to going to the ReceiptScreen which is not the goal of the test.
In this commit, we replace the use of `pay` method with a more granular series
of steps to make sure that the test doesn't click the validate button and will
properly make the succeeding checks on the amounts in the PaymentScreen.
closesodoo/odoo#117844
X-original-commit: d51fa82d1fa9e154b9f9d57a5532e8c5fe48e33d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer
have a relative positionning. As a result, most elements having an absolute
position and placed relatively to those elements will be incorrectly placed.
In website_event, the badges of the event cards are currently placed on
the upper border of the card because they are now placed relatively to
the whole card instead of the card body container having a `col-*` class.
As a result, the badges isn't where it should be and get cropped by the
container.
Steps to reproduce the issue:
1. Create a new event
2. Set a template
3. Go to the /event page
4. Click on the edit button from the Odoo navbar to edit the page (editor)
5. Go to the "Customize" page
6. Click on the "Templates" toggle button
To fix that issue, we will add a `position-relative` class on the card
body container having the `col-*` class. This ensure that the badge will
be placed as before between the card body and the card image.
task-3251110
closesodoo/odoo#117872
X-original-commit: 08f98194c095c541bf24d8ba55b440b189fd0766
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Issue:
With the "Extra Step During Checkout" setting,
it is possible to click on the "Configure Form" button
which should redirect us to the form in order to edit it.
However, we will always be redirected to the first website
(even if we have modified it in the settings).
Furthermore, if we don't have a cart in progress,
we will be redirected to the shop.
Solution:
Add a parameter specifying that it is for editing.
In this way, we can modify the form without having to create a cart.
Due to a technical limitation (reloading settings after saving),
we will always be redirected to the first website.
But it is possible to change the website (with the website editor)
and modify the second website if necessary.
opw-3245772
closesodoo/odoo#117870
X-original-commit: a3169ede4f609b56c83da04756d20b1c7a07251f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- Install website_mass_mailing
- Go to the frontend and activate the editor.
- Add a newsletter block, change it to subscription form.
Issue: The name of the newsletter is displaying also the number of
subscribers (e.g. "Newsletter (1)").
Solution: Change the name we are using to display the newsletter name to
use the `name` and not the `display_name`.
opw-3145571
closesodoo/odoo#117846
X-original-commit: 3930df6c06197b70a019caa4d6782453095a7c66
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
When creating a timesheet, if in the vals passed the AAL doesn't
have a company (possible since it's not required), then the `uom`
of the timesheet is False, which doesn't make sense.
Expected behaviour:
The timesheet `uom` should fallback on the uom of the company
of the project.
Steps to reproduce:
- Install hr_timesheet, Accounting
- Activate the AAL in the settings
- Create a project with an AAL
- Remove the company on the AAL of the project
- In that project create a task and log some timesheet.
- `uom` field should be empty
Reason for the problem:
When setting the `product_uom_id` in the vals when creating/writing
a timesheet, we just take the `project_time_mode_id` on the company
linked to the AAL. The problem is that the company on an AAL is not
a required field, so it can be `False`, leading the setting the val
for `product_uom_id` to `False`.
Fix:
In case the AAL has no company, we get the `uom` from the company
linked to the project.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3245671
closesodoo/odoo#117834
X-original-commit: 4cce77bd0288eeb3326ba57e91ef11d436f8a0ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit fixes the components destructuration for the
AttendeeCalendarYearRenderer extends.
closesodoo/odoo#117845
X-original-commit: 340e9c2416537fc2e46a914e6038e5233dd876b6
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The analytic distribution json field may contain a deleted analytic account.
This causes 2 issues:
- When retrieving plans - the analytic account ids are used to force additional plans (maybe applied by a model) - causing a record does not exist error
- Opening and closing the popup is required to 'clean' the distribution. this is not ideal as a draft invoice will not display the deleted account, but it is still in the json.
With this fix, the analytic accounts existence is checked, and the distribution json is saved without the deleted account.
closesodoo/odoo#117835
X-original-commit: ce5045d4ba5633790dfce1ef44c10b5770432829
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit: if there wasn't any mail group, and you add a
"Discussion Group" component to the website it will raise an error. The
problem is that the `'website.prompt` wasn't loaded.
The solution is to add the `website.xml` file path to
`web.assets_backend` in the website manifest.
opw-3184203
closesodoo/odoo#117824
X-original-commit: feed4ba6f0e904911de419a94998e22a2033f9f7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When only Invoicing app is installed, trying to switch from a CoA with
reconcile model result in the following error:
You are not allowed to delete 'Preset to create journal entries during a invoices and payments matching' (account.reconcile.model) records.
This operation is allowed for the following groups:
- Technical/Show Full Accounting Features
Contact your administrator to request access if necessary.
As we already checked that user doing that operation is an admin., we
do remove the preceding CoA a superuser (like it was done precedingly
in saas~16.1).
To reproduce:
- Install a database without demo data and choose "Germany" as country
- Install "Invoicing" app
* this automatically install SKR 03 chart of account *
- Go to Settings / Invoicing, switch chart template to SKR 04 and Save
* raise the error above *
closesodoo/odoo#117788
X-original-commit: 87af732ba99b0fd79a98aa0c0c09ca1f737f9955
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
The purpose of this commit is to return meaningful responses when
validating steps and leave the caller to decide what to do with them.
We also introduce a public action enabling the validation of a step
from its xmlid and handle the different cases including the missing
step.
Note: these features are currently used in appointment (See Ent PR).
Additionally, returning the newly validated `onboarding_steps` from
`onboarding_step.action_set_just_done` makes more sense than returning
the `onboarding_progress_steps` records.
Tests are updated to make sure of this.
Task-3074112
closesodoo/odoo#114572
Related: odoo/enterprise#37870
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Remove an option used by the phone widget in the res_user view.
task - 3246848
closesodoo/odoo#117805
X-original-commit: a998437ed465f1a2a0aaee3651472ff8c58ba067
Related: odoo/enterprise#39387
Signed-off-by: Kevin Baptiste <kba@odoo.com>
English term changed in source. Dutch and French via Transifex.
task-3193776
closesodoo/odoo#117789
X-original-commit: 8225fcfe0de231788952ec4c9f6d0eabdc387aa5
Related: odoo/enterprise#39372
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.
Now it takes 200 ms.
closesodoo/odoo#117738
X-original-commit: 5fc448e7f6dcce94fb89b23be29c4d38a525dd97
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When we use a 12 hour time format (without the `%p`), the time set is
always in the morning regardless of the period used (AM or PM).
Using `preparse` and `postformat` in the locale to change the symbols
used for numbers prevents the user from changing the date in the
datepicker because the date will be unparsable
Steps to reproduce:
1. Install Calendar
2. Go to Settings > Translations > Languages and open 'English (US)'
3. Set the time format to `%I:%M:%S`
4. Open Calendar and create a new meeting in the morning
5. Edit the meeting, set the time period to 'PM' and save
6. The time of the meeting doesn't change
Solution:
Get the time from the event passed when we close the bootstrap
DateTimePicker and convert it to luxon.
The period displayed when we open the datepicker is always 'AM'. This is
a limitation with the bootstrap DateTimePicker that uses the value from
the element[^1] (which is already formatted with the 12 hour format,
without the period info). Hence, the time is always in the morning
Problem:
The value of the element is used to set the date but this value is
already formatted with the 12 hour format (without the period info) so
it's always in the morning
opw-3150033
opw-3233229
[^1]:https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/tempusdominus/tempusdominus.js#L395closesodoo/odoo#117781
X-original-commit: dc195613ecff17d6aadc6e6ad8ab6da3670eb85a
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When opening the Time Off App, the JS performs an rpc to call
hr_leave_type.get_days_all_request. Inside this method there are
some __get__ on non-stored computed fields. This triggers
a recomputation of said fields in _compute_leaves. _compute_leaves
uses _get_employees_days_per_allocation.
When there is an hr.leave.type with request_unit = 'hour', you may
get lots of validated allocations by employee. When this is the case,
_get_employees_days_per_allocation gets quite slow, especially the last
part about 'Future available leaves'.
This commit optimizes this part of _get_employees_days_per_allocation.
In this part the allocations are grouped by employees
and Intervals instances are of the form (start, stop, records). This means
that for a given employee_id, all the records of one Intervals will have
the same start and stop values. This allows us to move the call to
_get_work_days_data_batch outside of the
for future_allocation_interval in future_allocation_intervals._items loop.
Because _get_work_days_data_batch is quite expansive, moving it out
grealty speeds up the _get_employees_days_per_allocation method.
Example speedup: in a database with 50 validated allocations for
the same hr.leave.type and employee_id, the timing of
_get_employees_days_per_allocation 7.39s -> 158ms
opw-3123457
closesodoo/odoo#117778
X-original-commit: 5a2efd2e5c3e65502c031f79f85319f3351f66e3
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Paolo Gatti (pgi)