Incoming shipments are marked red according to creation date which does
not really make much sense.
closes#1061
note: it was already like this in 8.0 with 201f1c323
There was a traceback when opening the purchase.order model in form view as the
field 'invoiced' is used in domains, but has been removed from the template at
rev. eace69d07d.
When creating an event in at 4 pm,
while being in UTC +2 (Europe/Brussels),
The start date sent to Google was set as
'2015-07-03T16:00:00+02:00',
but the timezone was described as 'UTC', giving
therefore giving contradictory information.
At the end, in the google calendar,
the event was set in the UTC timezone,
while it should have been set in GMT +2 (Europe/Brussels).
opw-640825
The widget_x2many tour uses the discussion model to test one2many
and many2many widgets. The tour clicks on an item of the menu which
opens the discussion model with the discussion_form_2 view (in create mode).
Then, it clicks on the view_switcher to display the list view, and clicks
on an item of the list to open a previously created record.
In the new design, there is no more view_switcher in form view. This flow
is thus unfeasible. This solution changes the menu action so that it
directly opens the model with the list view, on which we can click on the
record to display in form view.
When column 'writeoff_amount' gets displayed on a tree view and function
_get_writeoff_amount() is called with multiple ids, the returned amounts keeps
getting bigger every row.
Closes#7211
This rev. generalizes the notions of FieldOne2Many to FieldX2Many and of One2ManyViewManager
to X2ManyViewManager. The same logic is now applied both for One2Many and Many2Many fields.
This allows Many2Many list and kanban views to have a pager, as the pager is instanciated
by the view, on demand of the ViewManager.
Apply the same style to many2many form_field as for one2many ones.
Make the sales_team cards for team members clickable.
Add "position: relative" to sales_team cards for the cross to be correctly
positionned. Inline style is not the right way to do it, but for the sake
of consistency, it is ok. A better commit should come to remove this inline
style from all x2many kanban templates.
Before this rev.,
if you define a carrier
- without advanced price rules
- with a normal price set to 0.0
- Free if more than amount unchecked
When you try to invoice a delivery order
(coming from a sales order with as invoicing policy
"on delivery order)
No grid was found, while there was one, with as price 0.0
Closes#1364
The number displayed in the Sales button shows the number of sale order lines confirmed
for the current product.
The number displayed in the Purchases button shows the number of purchase order lines
for the current product.
closes:#7107
The amount total computed for pos order must be the sum of the rounded tax amount
and the rounded untax amount. Inspired from _amount_total in "sale.order".
opw:643254
Don't retrieve the binary contents just to display the size, but pass context
with bin_size=True instead
Always pass filename in download link
Combination of patches from the bug report from Enrico Ganzaroli, Cedric Le
Brouster and Holger Brunn
Fixes#4899, lp:1167429
View validation accounts for a fair cost of module installation, most of
that is spent checking for view validity, and a significant fraction
of *that* is spent reading the validated view from the DB.
Turns out _check_xml requested *all* view fields even though it needed
none of them save for the arch. Specifying fields to read_combined
rather than fetching all fields seems to result in a ~30% speedup of
_check_xml (under line_profiler). Most of the rest is spent fetching
sub-views (in get_inheriting_view_arch), I don't know that it can be
improved without hand-crafting a fairly complex SQL request.
In account_budget module,
when creating a budget position,
the user can select view accounts and also accounts with consolidation children,
in addition to normal accounts.
However, when viewing budgets with positions containing only view accounts,
the "practical amount" field was always zero.
Since these type of accounts are accepted as budget positions,
the system should take into account children and consolidation children
when computing the practical amount.
Fixes#372Closes#1247
Tam Vu