RUNNING_TOUR_TIMEOUT is equal to 10 seconds, which sometimes is not enough on
travis and we need a way to increase timeout per step.
Note: Exact same commit was already merged for version 11.0 here: 67e2372
Note 2: this is technically a IMP, not a fix, but I (GED) will accept this, since this should only impact the testing functionality. Also, this was done in 11.0, so in some sense, it was proved to work.
(PR: #21750)
When a pricelist was set on the public user that was different from that of the
website, the prices were displayed using the public user default currency,
but the currency symbol displayed was the website default currency.
The issue was that in the template, the currency was accessed as a computed,
related field of website while the price was obtained using a function call.
In the first case the field was obtained using sudo, and thus the call would not
get the public user pricelist.
Equivalent to #23519 for odoo 11.0
opw-1819230
- Set 'Round Globally'
- Create an excluded tax of 10 %
- Create an invoice for a product costing 34.55, and apply the tax.
The tax on the invoice is 3.46, while the tax on the tax line is 3.45.
When rounded in `compute_all`, the tax amount is 3.455, which is the
value expected. However, the `create` method won't round this value
before storing, leading to the inconsistency.
We make sure to round the amount to the currency precision, so the
value 3.46 is recorded.
opw-1819902
Issue: when the inverse method writes on a dependency of the first record, it
invalidates the cache of the field for the other records... Solution: simply
evaluate the inverse method one record at a time.
When the `create` or `write` method receives an empty string for a date
or a datetime field, PostgreSQL will fail since this is not an accepted
value for this field type.
We fallback on `None` for falsy values.
opw-1819336
@KangOl : watch out when forward-porting, the signature of
`convert_to_column` has changed in saas-14.
Before this commit, when clicking on a event of a pinned calendar view
in the Dashboard app, nothing occurs.
The cursor turns into pointer type when hovering on an event, suggesting
that clicking on it should do something. Kanban and list views redirect
the user to the document's form on click, so a similar behaviour is
expected with calendar view.
This is indeed the case in v11, but not in v10. The reason that it works
in v11 for calendar is that when we click on a record of a pinned views
in dashboard, it performs a do_action to open the form view. In v10, however,
it performs a do_switch_view to the form view. Since there's only one view mode
when we pin something in dashboard, the processing of the click fails silently.
Kanban and list were working because the dashboard app overrides their
handlers functions when loading the views, which wasn't the case with calendar.
This commit solves the issue by also overriding the handler function
of calendar view, so that it performs a do_action to open a form instead
of performing a do_switch_view to the form view.
(Note: pivot and grid views work, because they use do_action)
opw-1817725
Properly override `_track_template` similarly to what is done for
`project.task`, so the method can accept a recordset.
Co-authored by: Nicolas Martinelli <nim@odoo.com>
Closes#23466
opw-1823244
Before that, partial payments on open invoices were ignored by the query, due to the fact we used checked "reconciled=false" instead of "full_reconcile_id is not null".
Before that, partial payments of invoices were not shown into the partner ledger unless the option to show reconciled entries was activated. This was due to the fact we checked full reconciliation with the field "reconciled" instead of the full_reconcile_id, so the query did not return the partial payments (which have reconciled=True, but don't have any full_reconcile_id unless the invoice is fully paid).
Use case:
Have a user with access rights "See Own leads"
In the CRM settings check the "use leads" boolean
Before this commit:
This user couldn't create a lead directly nor qualify it as an opportunity
AND
the default sales team on the lead displayed as 'Unknown'
After this commit:
This user can read the sales team, even though he is not a member of them
He can create leads on the default sales team
And qualify them as opportunities
OPW 1816309
ref #22360
Make an invoice
Make a payment
Unreconcile them
Before this commit:
The invoice and the payment weren't display in the aged partner balance
After this commit:
Both payment and invoice *can* be included in the balance
OPW 1819359
- Set the product price decimals to 5
- Create a product costing 0.32
- Create a pricelist with 20 % discount when quantity is > 100
- Set a default fiscal position on the POS
- Lauch a POS session
- Add 500 units of the product
The unit price is rounded to 0.26, while it should be 0.256.
This is due to the call to `compute_all`, which will round to the
currency precision.
opw-1816997
The payment lines shown in the payment widget on invoices, should only list reconciliation made towards the lines sharing the same account as the invoice/bill. Previously, if a tax or an invoice line was using another account set reconciliable, any payment made against this account would be shown in the payment widget, which is wrong.
OPW: 1805968
On creation of a new landed cost,
in the web client,
the name was filled with the next sequence
`self.env['ir.sequence'].next_by_code('stock.landed.cost')`
but then, as the field is readonly,
it is not sent in the create values to the server,
and therefore the server sets again the default value
and generates a new sequence name.
The previous assigned sequence name is therefore never assigned,
and there was an obvious gap in the landed costs sequences.
Besides, using a sequence as a default is never a good
idea, as the record can be discarded, and this will not discard
the sequence number that has been used. There will be again
a gap in the sequence.
See this forum topic for reference:
https://www.odoo.com/forum/help-1/question/how-to-handle-reading-and-writing-to-read-only-fields-2247#answer_2281
I therefore remove the default value,
and use the exact same behavior than on the sale order,
which is pretty similar:
- The default value is set to `New`
- Then, on creation, it is replaced to the actual sequence number.
https://github.com/odoo/odoo/blob/bfe88c50e2b4975a23c624cc5b5171158bb9f855/addons/sale/models/sale.py#L273-L279
opw-1823133
Note: This can be back-ported to Odoo 9.0,
but the fix will be different since the module has
been converted to the new API since then.
If I did it in 9.0 in the first place,
mostlikely it would not have been forward ported correctly.
msgid ""
"You cannot set a negative product quantity in an inventory line:\n"
"\t%s - qty: %s"
Was creating a ir.translation record with a src as
You cannot set a negative product quantity in an inventory line:
t%s - qty: %s
('t' instead of \t)
Closes#23541Fixes#23521
When a membership line has its dates changed
(date_from, date_to, date_cancel)
The membership start/stop dates on the member
(res.partner) were not changed accordigly.
opw-1823981
In a multi-company environment,
if a user in company A
created a Payslips batch for an employee in the company B
and used the `generate payslips` button,
the created payslip was set with the user company (A) while
it must be the employee company (B).
opw-1820138
Before this commit:
Expense emails title are parsed to find a product that match the given [CODE].
For example, an email title like '[CARD] Graphic Card $900' will create an
expense for the product having 'CARD' as internal reference.
Since the search is done with an 'ilike' and with no 'limit', it could return
multiple product: all the one containing the CODE in their internal reference.
This would throw a singleton error when trying afterward to read product.id.
Then, the mail would not go through the mail.thread flow and it would return
a Mail System Delivery fail saying the address does not exist.
Users would get stuck with this, having no way to understand where the error
comes from.
Now, we ensure to find only 1 product.
To avoid breaking the ilike behavior that could be used by users only typing
the first caracters of a long CODE, we still use ilike but force exact match if
there is multiple results.
Closes#23419
opw-1816340
Set up a delivery method that has a country set on it, but no states
(e.g. USA)
When the client is required to fill his address info in and when he chooses USA as the country
Before this commit:
The selection field where the states are selectable is not displayed.
After this commit:
All the states of the country are selectable
The usability choice is to say that if states are not specified on the delivery method
that means all states are supported
OPW 1818591
- Define 2 companies A and B. Delivery methods are linked to products in
company A
- Deactivate 'Share product to all companies'
- Create a user B in Company B only
- As user B, create a SO and open the drop-down list for delivery
methods
An access error is raised.
Delivery methods should follow the same record rules than the products
they are linked to.
opw-1815490
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
view in the closest instance of a ViewManager-like widget in the
SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
Have your OS be in Vancouver with time = 15:59:00
We are on day X
Have a next activity on a lead, scheduled for today
At 15:59:00 the next activity is not overdue
Before this commit:
Past 16:00:00 the next activity becomes overdue
This is because 16:00:00 is 00:00:00 in UTC (+8 hours)
And the next activity is scheduled for day X
But in UTC, we just passed at day X+1
Hence, the next activity being overdue
After this commit:
The next activity is not overdue, since we are actually on day X
OPW 1815323
Ivan Yelizariev