Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69
After this commit, it doesn't crash
OPW 1913133
closesodoo/odoo#29094
Usecase to reproduce:
- Enable 'Managers must approve orders'
- Set agreement type as 'exclusive'
- Connect as purchase user
- Create a requisition and an RFQ linked to it
- Confirm the RFQ
It raises a usererror that ask to close other PO linked
to requisition.
It happens because the purchase requisition code do not take
care of double validation on PO. It will try to close the requisition
once button_confirm is called. However it will only write 'to approve'
on PO state and thus trigger the requistion error will be raise since
all linked PO are not 'done' or 'cancel'.
In order to fix it, the action_done on requisition should be call
on button_approve instead of button_confirm. (button_approve is
automatically called when double validation is not enable).
Task: #1884410Closes#28068closesodoo/odoo#29049
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
This commit tackles the issue of having the pseudo-object 'parent' in the
invoice lines views
In the regular o2m, parent refers to the current invoice
From commit eca030cc38
we learn that parent.get() is not a valid field according to python
From OPW 1912243, we learn that:
- when the invoice line form view is standalone (not popped from the o2m)
'parent' is not what we expect (in this case it will refer to the record list of all invoice lines, NOT the invoice)
- parent.type in that case is undefined and makes the JS crash
So, to make sure we retrieve the right field and value, we retrieve them through
related fields pointing to the invoice
closesodoo/odoo#29074
Have an expense product with a supplier tax on it
Write an email to be caught by the thread model to create an expense for that product
Before this commit, the tax was not set up on the expense
After this commit, it is
OPW 1908596
closesodoo/odoo#29061
Have a form record with a progress bar
Modify the max_value of the progress, as well as the current_value bar through an onchange
Before this commit, the new max_value was not taken into account
After this commit, it is.
closesodoo/odoo#29056
Have a sales team without a target in the kanban view
click on define a target
Before this commit, the veiw wasn't rerendered, so the change apparently did not happen
(while the write was triggered)
Also, the Enter key did not work to validate the input
After this commit, the view is refreshed and the enter key works
OPW 1906938
closesodoo/odoo#29055
Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
To generate the values for the attachment, a regex is used to parse the content.
Besides summoning Eldritch abominations, it didnt't take into account the
original filename, whereas the default one (image) would have no extension.
We extend the regex to capture the filename and use it.
opw 1903194
closesodoo/odoo#28527
Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
However it did give a res_model value of mail.message but no res_id;
add_missing_default_value would fill in the res_id from the _context, which is
not the mail_message but the current object on which it applies
(e.g. helpdesk.ticket).
We put the correct res_model along with the res_id.
opw 1903194
closesodoo/odoo#28526
When creating a SO line and clicking on search more for product_id
Before this commit, every user had the button "Create" to create a product.product
After this commit, only user in groups that actually can create a product have the button
OPW 1910371
closesodoo/odoo#28924
When creating a mail for a user in an other company then the
record, the "send" button fails with a traceback because on
specific template try to access the company.id of the user
which is not accessible due to the access controle.
This PR fixes the problem by sudoing the access to company id.
The mail now sends without problem.
Step to reproduce:
1. Use two companies (comp1 and comp2)
2. Use 3 users (user1, user2, user3)
3. Be sure every user has a confirmed account
4. Change the users to set both company as allowed.
5. Set the current company of the users as follow:
user1: comp1
user2: comp2
user3: comp2
6. Install the project module
7. In `settings > security > record rules`, archive the rules named:
- `Project: multiple-company`
- `Project/Task: multiple-company`
- `user rule`
8. Using user1, create a new project and a new task.
9. Using user2, go to `Project module > Search`, remove `My tasks` filter,
select the task created by user1, in the chatter add user3 as follower.
10. Send the mail => access error.
The `AccessError` is due to user2 trying to access comp1, in particular
`company.name`.
By adding a `sudo`, we also make sure that the template rendering won't
fail bacause of a similar `AccessError`.
opw-1907844
closesodoo/odoo#28710
Define a x2m tree view with a default_sort including more than 1 field to order the list against
Before this commit, the second field was never used
After this commit, it is used
OPW 1909785
closesodoo/odoo#28840
When opening the Manual Reconciliation widget, all partners with opened
invoices and payments are fetched.
In some cases, the database might contain a lot of partners without any
reconciliation suggestion; therefore, the partners with suggestions are
'lost' in the view.
This commit sorts the data: we first display the parters with a
suggestion, then the others. This should improve the usability of the
view.
opw-1903575
closesodoo/odoo#28958
Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
Embedding a video can't work because it embeds an iframe, which is not supported
by most email clients for security reasons.
(What happens when Gmail shows embedded videos in displayed emails, is that you
send a link in the email body, and it is at rendering that Gmail adds the iframe
into the page.)
So the bugfix solution is to hide the button.
Since there is an option "res_model" that allows us to know when we are in that
case, we remove the video option.
opw 1905497
closesodoo/odoo#28911
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
Lucas Perais (lpe)