In the case of calculating payroll, we don't want to convert the
datetimes using the timezone of the user as we really want to see what
the employee has done from one date to another (usually from the start of
the month to end of the month)
Closes#26256closesodoo/odoo#28977
Fine-tuning of commit: o50f77ba091189bd785d459c042a6cec04a125fdb
When costing is in FIFO mode, product price can be updated whereas the current
user doesn't have the right to modify the products.
It therefore introduced a sudo() to make this computation;
however since this is modifying a company-dependent field,
a force_company was missing to update the correct one.
Closes#28487
opw 1907377
closesodoo/odoo#28662
- This commit fixes a crash that happens when the server receive a
JSON-P call done in two requests (a POST followed by a GET).
The issue is due to the fact that when the first request is done (POST
one) the member `params` is never initialized.
This parameter is then used in the module `auth_signup` on an override
of the method `dispatch` thus crashing the code.
To avoid the crash, we now initialize `params`.
closesodoo/odoo#27369
Have a recurring meeting, repeated until some date
Edit one of the instances and detach it (click on "update only this instance")
Edit the detached event and change some value
Save
Before this commit, a JS error was thrown saying that the field final_date was invalid
This was because the required attribute on this field was set to True, but the python
put the value of the final_date to False
After this commit, there is no error as we set this value to false, since the field
doesn't make sense for a non-recurring event anyway
OPW 1892426
closesodoo/odoo#28850
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
closesodoo/odoo#28542
Purpose
=======
Buggy example:
I have a 35h working schedule. I work every week day:
- From 8h to 12h
- From 12h to 16h
Let's say that I want to retrieve the working hours from Wednesday 14h03
to Thursday 11h03.
The working hours are:
- From 14h03 to 16h --> 1h57
- From 8h to 11h03 --> 3h03
----------------------------
TOTAL 5h
Currently the result will be 1.95, i.e. 1h57 because the second day
is not taken into account as start time > end time, and thus rrule
doesn't manage this correctly and returns only the datetime corresponding
to the first day.
Specification
=============
Force the until parameter of rrule to be set at the end of the day, do
avoid skipping the second day. Do this in the methods that compute the
work hours and the leave hours.
Add a test to ensure the robustness of the fix.
Closes#21297closesodoo/odoo#28920
This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.
Up to now,
the supported wkhtmltopdf version was 0.12.1.
The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.
There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.
To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.
This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)
opw-1907346
closesodoo/odoo#28864
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28923
Steps to reproduce the bug:
- Let's consider a product P with a BOM in kit
- Create a PO with P and confirm it
- Cancel the shipment and the PO
- Reset to draft the PO and confirm it
- Valide the new shipment and receive P
Bug:
The qty_received was not updated
opw:1904678
Create a coupon/promotion that gives a 100% discount on some digital product.
If the total of the order is 0, then the client won't have the possibility
to download the product(s), since the download links appear on invoiced lines;
and no invoice has been created.
We display the download link on the products if the order total is 0,
as the other cases are already covered by the existing code.
opw 1905682
closesodoo/odoo#28799
By removing the `.id` from the `partner_id.id` domain leaf,
the ORM avoids to do a useless `SELECT` to read
the id of all partners different from the public partner,
as it already got the information from the `sale_order` table
e.g
Here is the SQL request before the revision:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
Here it is after:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" != %s)) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
closesodoo/odoo#28927
The adaptation to Python 3 was done with two mistakes: the iteration on the lru
cache does not return keys, and functions are not sortable.
closesodoo/odoo#28870
For a SO of 300 lines, when confirmed, it takes 195s to process stock
moves for the SO, which is an insane amount of time for any kind of
process in Odoo.
This happens because stock.move is a heavy model with lots of fields,
prefetching all these fields at once can hinder performance when
processing a lot of stock.moves.
To reduce the processing time, the prefetching is disabled in the
specific scenario of processing stock moves and pickings on SO
confirmation.
This patch increases the performance of SO validation (with stock
installed) by ~30%.
Pre-patch: 195s (300 SOL)
Post-patch: 135s (300 SOL)
closesodoo/odoo#28835
With the purchase module, when you create a new vendor, you can
select what variant of the product the vendor sells. The droplist
has the "Create & Edit" button to quickly create/edit variants.
This is not the wanted behavior. This PR removes the "Create & Edit"
suggestion.
opw-1909009
closesodoo/odoo#28845
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closesodoo/odoo#28766
The POS js tests expect the "Public Pricelist" when
selecting a lambda customer in the pos interface.
Nevertheless, when installing a localization
with a specific currency,
other than the currency of the public pricelist,
it creates a new pricelist called
"Default %(currency)s pricelist for %(company)s"
and sets it by default for the customers sale pricelist.
See
https://github.com/odoo/odoo/commit/787e1037cdca48fe361ae65d790056a3d57e6b67#diff-840bfc6fc7a986fbf0e248c83d2ac1d5R57
Therefore, in the POS js tests, the pricelist selected
when selecting a lambda user was no longer
'public pricelist' but the one mentioned above,
and the tests therefore failed.
The issue is solved by creating a dedicated "Public Pricelist"
for the purpose of these tests, and sets it by default
for the customer sale pricelist,
as well as for the pos config default pricelist.
The test case was to install `l10n_pe` with `point_of_sale`
while activating the test.
e.g. `-i l10n_pe,point_of_sale --test-enable`
opw-1890928
opw-1910249
closesodoo/odoo#28839
- Configure the company in USD
- Set-up the POS in EUR:
Pricelist in EUR
Payment journal in EUR
Sales journal in EUR
- In the POS, sell a product (in EUR)
- Validate the session and post entries
The entry amounts are the EUR amounts, but they are posted in USD.
Long story short: nothing was foreseen to convert the amounts in the
appropriate currency.
Fixes#27175
opw-1904146
opw-1910248
closesodoo/odoo#28785
Implement the getter method in plain SQL. This makes reading company-dependent
fields 33% faster (on 20000 partners, reading 'property_product_pricelist'
takes 3700ms instead of 5500ms.)
closesodoo/odoo#28769
In the case of a One2many list view in a `<group>` tag, the 'External
Link' button of a Many2one field (which allows opening the form view) is
not visible.
The `flex: 1 0 auto;` should not be applied in the list view.
Corresponding PR in v12: #28741
opw-1903158
closesodoo/odoo#28812
Steps:
- open a modal form view from tree view first line and make a change
- open a modal from the second line and make a change
- open the second line back: the change were lost
In a given number of conditions (a many2one inside the form view, there
is a one2many in the form view not inside the tree view, ....) this
happened because:
- when we save the first line, we get onchange data for the second one
- this onchange data can't be applied before second line is loaded, but
it is saved so it can be applied if second line is ever opened
- when the second line is opened the saved change is applied => OK
- when the second line is opened a second time the saved change is
applied again, possibly overwriting posterious change => BAD
With this changeset, when the record with unapplied onchange is loaded
for the first time, the unapplied onchange is applied only once.
Added test without the change failed with:
- only 1 turtle for second partner (result: 0 not 1)
- second partner turtle is Michelangelo (result: "" not "Michelangelo")
opw-1846820
closes#28644
This field is a dependency of some computed fields, and has to be searched on
for triggering recomputations. Without the index, the creation of stock moves
becomes slower as the table grows.
closesodoo/odoo#28757
On firefox if we do for example:
ALT+GR + [ALT+GRable ´ key]
Firefox may send keys "AltGr" and "Dead" instead of just "AltGr".
This was possibly causing caret to go a position too low when writing
speedily with diacritical marks.
opw-1903865
closes#28739
Fine tuning of this commit:https://github.com/odoo/odoo/commit/7501691da9a9dae832b7d6e78c6a5f57fc983b5c
Fields signup_token, signup_type, signup_expiration are protected
When sending a quotation (mail template 'Sales Order - Send by Email'):
the token needs to be read (and sometimes written)
opw:1907157
Create an invoice for a day, and register a payment right away
BUT choose a date in the future for that payment
Imagine a French Check. You write it, and tell your partner to cash it in
10 days later
You would enter that transaction as a temporary payment
in your own books
OPW 1893646
Before this commit, the line of the partner did not appear in the aged
report after if the report was for the date just after the invoice date
After this commit, it does
closesodoo/odoo#28728
Steps to reproduce the bug:
- Set decimal precision to 7 for products.
- Order 2.000000 of a product.
- Deliver 2.6791200 of the product.
- Go back to the Sales order and change the ordered quantity to 2.6791200.
Bug:
A UserError was raised: "You cannot decrease the ordered quantity below the delivered quantity."
opw:1904580
closesodoo/odoo#28674
commit c6b0d36622 introduced a wrong
domain. The readonly should be added if the show_operations is false
OR state is done AND is_locked is true.
close#28595
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28603
Have a company that do not have a logo.
Try to print a "PDF report" from the accounting module
Before this commit, the simple company form popped up
with the purpose of force setting a company logo
After this commit, we assume it is not necessary to have a company logo on the reports
Note, because of 733ce266ef, we cannot do a save and print
OPW 1904764
closesodoo/odoo#28617
RomainLibert