Before this the mrp.document id was used to construct the /web/image/
link which lead to the wrong attachment being previewed and
downloaded. Introduced by the refactoring that happened in
d193350c6f.
The o_row class mechanism is supposed to be used to put another
element next to a field, like a button for example. However,
in the case of phone and email field, the o_text_overflow hack
gets in the way.
The problem that o_text_overflow is trying to solve is when you
have a long email, the table used to display the form view fields
tends to use very long cells (td) so it can display the whole email
address. This behavior completely breaks the form view, even though
the email address is clearly set to wrap in css. The o_text_overflow
class is a hack that forces the table to think that the email is
small, then defaulting to the width 50% css rules. If the email is
too long, it is correctly wrapped inside the cell, without breaking
the form view layout.
However, when we need to add a button next to those fields, this
hack gets in the way of the o_row class css rules, completely
wrecking it. We looked for a fix with qsm-odoo for hours but were
unable to find one that did not require a complete rewrite of the
form view css rules. In the end, we decided to remove the hack from
the phone field and keep it on the email field, as we think it is
less common to have a very long phone number than to have a very
long email.
There is a double-check (on client and on server) to prevent the user to
upload a >25 MB document. The client checks the actual file size while
the server guesses it from the total received payload. This server guess
is wrong as the extra payload is quite huge (5-10MB). Now the server
checks the real file size as it should have from the beginning.
In calendar views, the breadcrumbs should display the period
displayed in the view (e.g. in month mode, something like 'April
2017'). Moreover, the 'Day', 'Week' and 'Month' buttons should be
highlighted when the corresponding mode is used.
This rev. ensures that this is the case.
Before this commit, if a reminder was created and the dates being
formatted contained unicode characters the whole thing would break
because python + unicode is hard.
Example: Japanese with Asia/Tokyo timezone and creating reminders
of 1 day, see support ticket 771674
The signature of the function _compute_quantity is
_compute_quantity(self, qty, to_unit, round=True, rounding_method='UP')
With courtesy of @PierreFaniel
Closes#19682
opw:774104
Method which return summary information about the registration,
which can be used by email or QWeb templates to fetch useful
information about the registration.
Purpose
=======
Currently, if we want to print an expense report that has several currencies in its expense lines, the total amount is hidden on the report. Otherwise, it is simply summed.
That could lead to confusing uses cases. Example.
1 expense line of 92 dollars.
1 expense report expressed in euros.
In the report we will have
- 1 line of 92 dollars
- Total amount: 92 euros
Which is obviously wrong.
Specification
=============
Always display the amount + Compute the amount in the expense report currency, by converting the amount with the rate at the day the expense has been made.
Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.
This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
old destroyed domain selector
As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.
when coming back using the breadcrumbs.
The settings form view should always be displayed in 'edit' mode.
Before this rev., it was re-rendered in 'readonly' when the user
clicked on a link in a setting view (opening another view stacked
in the breadcrumbs), and then came back to the settings view using
the breadcrumbs. For instance, go to 'General Settings', click on
'Activity Types', come back.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
A product can have multiple included taxes (i.e. one by company).
When computing the product price with function _fix_tax_included_price,
only the taxes of the company should be considered. Otherwise it could remove
all the included taxes of all companies.
ps: When no company is set on the SO, all the taxes visible from the company of the user
are set for the product of the line. Same behavior as in _compute_tax_id.
Closes#19566
opw:770464
Before the new views (SAAS15 and before), the 'readonly' modifier was
kind of weird: a field which was in a readonly state was not saved (the
field was not present in the RPC), UNLESS it is a subfield (for a
x2many).
With the new views, we changed the semantics, to make it more consistent:
fields in readonly state are never sent to the server. This is a much simpler
semantic, but it may introduce some problems, when we actually want to
save the record. This is solved with a new attribute 'force_save',
where we explicitely have to declare which fields should be save, even
if they are in readonly mode.
In this commit, we simply add the missing force_save attribute to the
order line form view. This allow the user to create a new SO, add an
order line with some invoice line, and save the result (without this,
the server complains about a missing product_id field)
- Create a product with:
Product UoM: kg
Purchase UoM: lb(s)
Tracking: By lot(s)
- Purchase 100 lb(s), validate and receive picking (set lot 001)
- Return the picking
- Set the lot
The quantity to do is 45.36 instead of 100.
We make sure to convert the quant UoM (=Product UoM) into the
appropriate UoM.
opw-771930
Modifiers (eg. required, readonly, ... on a field) are computed after a
record has been changed. When loading a record they could be computed
based on x2many in a inconsistent state.
eg. on res.partner form, by defaut the email is required depending on:
[('user_ids','!=', [])]
but when switching from one record to another this was computed
wrongly based on the difference between the two records.
This change make the x2many when loading a record ready to be used as
soon as it is set to solve this issue.
forward-port: not needed after saas-15 thanks to framework views rewrite
fix#18239
opw-749483
closes#18815
The method _procure_orderpoint_confirm in stock/procurement is calld in sudo() by run_scheduler.
Even if this method receives the company as parameter, the company is not enforced for all
the processes trigerred into the method. i.e. If a PO is generated by the run of the procurements
the sequence used is the one of the admin's company and not the one for the given company.
To enforce the company to use, we force the company into the context if it's not the same as
the user's company.
opw:771851
Add a `peek` option in the bus event dispatcher polling in order to let
an external event dispatcher fetch the notifications and their
corresponding channels.
Cherry-pick of rev. f2f99dc091
Only start the bus events dispatcher when needed (lazy starting).
On Odoo PAAS it's never started because the platform has its own event
dispatcher.
Cherry-pick of rev. a2ed3d3d5b
Traceback by pressing enter when changing partner which should not occur as keyUp event is
in place for other M2O fields and not for the partner.
In some case, if the line is balanced (marked as reconciled) and we change the user for one that does
not have any move lines, we removed the selected proposition but we did not changed the line balance, resulting
in a widget that is marked as inactive and no way to do something with it.
/!\ Should not be forward-ported in saas-18
Fix bug introduced by https://github.com/odoo/odoo/commit/e59c1b49c2d9729e5f7576e1c205701a340f9396:
When creating picking types, a color is automatically assigned. This
color is chosen to be the first available one, or by default 1 (since
mentioned commit, as '1' would be the default gray used in kanban
headers). Unfortunately, this was expressed as `color = first or 1`...
which will always be 1 since the very first available color is always 0.
On an invoice:
- Select a partner with payment term defined => due date D1 is set
- Change to a partner withour payment term defined
The due date D1 is kept.
opw-772063
The FieldDomain allows to open a list in a dialog to display the
records matching the current domain. In this dialog, clicking on
a record should do nothing (this was the behavior before the new
views).
Before this rev., it actually tried to open the record and it
produced a crash.
Scenario: Go to any list or kanban view: go to next page and set a
filter that matches less that 'limit' record (e.g. less than 40),
but at least one. No record will be displayed, because the offset
is kept for the search_read.
This rev. ensures to reset the offset to 0 when a search is done
using the searchview.
Olivier Dony