The computation of the total_invoiced field did not work in batch mode.
When displaying a company in a form view (field invoice_total comptued), the
children of this company are present in the cache and the value of the field
invoice_total will be prefetched for these children as well (at least in 9.0).
Most of the time this is redudant information and the same value is computed
for each child while most of the invoices are on the parent.
Batching the computation per partner allows to make one global query for all
partners.
Add test to make sure the total increase correctly after a test invoice
confirmation.
When browsing a form with a one2many / many2many field
with several pages, the one2many pager page was not reset
when going to the previous/next record, while the next/previous
record could not have multiple pages on its one2many/many2many,
and the page on which the user was on the former record could
not exist in the newly displayed record.
Besides, even if the page does exist, there is no reason
to display this new record X2many value from its first page.
It's the case anyway when you edit/save, it comes back to the first page.
opw-679092
Bug introduced in 7eab8e2.
As `self.env.user` is browsed with `sudo`, the result of this call
will always return the admin's current company and not the user's current
company.
opw-681809
With the pricelist, it is possible to define a pricelist just for
a variant. But in the product.product.form, only the pricelist items
linked to the product template could be displayed.
The field item_ids has been created in product.product model to display
all the pricelist applied on a product.
opw:674700
Basicaly, do this RPC once, at webclient startup, to get the next notification.
Do the RPC again when the notification is displayed to get the next one.
When an event with alarm is created, edited or removed, trigger an event on the
bus for all involved users (the attendees) with an update of their next
calendar notification.
Before this commit, the list view, grouped by a selection field, displayed the
'technical' value of the field as group label. It was basically forced
to do that, because the result of the read_group only contains the
technical value.
This commit changes the list view in a way that it now requires a full field
get, so it can use it to find the correct string.
Let's take the following case:
- Enable lot tracking on a product
- Costing Method is "Real Price", Inventory Valuation is "Perpetual"
- Create a picking with 2 stock moves, each stock move is linked to the
same product
When the picking is validated, 4 account moves are created instead of 2.
This occurs because the list of stock moves and the list of reserved
quants is sent to the method `_move_quants_by_lot`, but there is no
check to which stock move is related a given quant.
For most cases, the issue doesn't show up since there isn't usually 2
stock moves with the same product in a given picking. There is at least
one use case where this happens: selling a pack of two identical
products. In this specific case, 2 stock moves of the same product are
created, but one pack operation will merge the 2 stock moves.
opw-680308
_('foo '+bar) does not work as `bar` is a variable with undefinied content
during translation export (and variable content during evaluation) so a match
will not be found.
Also trailing spaces are stripped during synchronisation with transifex.
The proper syntax would be
_.str.sprintf(_t("foo %s"), bar)
but to avoid breaking existing translations (need to reexport .pot)
use the syntax
_("foo ") + " " + bar
that is more stable friendly.
The 'No value found for the field...' string is not possible to be fixed without
breaking the translations should be split at least twice.
Write it the propre way directly.
These accounts are created automatically on the journals creation
e.g. On the creation of a Bank Journal, a Bank account is automatically
created, linked to this journal.
Before this revision, when installing the generic chart of account
(or l10n_us), you had two Bank accounts (101400, 101401),
and two Cash accounts (101500, 101501),
by default,
which is not right.
opw-676950
Search engines (or one at least) truncates the description at 160. The advised
size is between 150 and 160 so no need to force a smaller size. It's a good
idea to keep it at 155 but larger sizes should be allowed.
cf: https://moz.com/learn/seo/meta-description
We could fully remove the limit as there is corner cases where a longer size is
used (https://moz.com/blog/i-cant-drive-155-meta-descriptions-in-2015) but this
should be in addition with an indication for the user of the current size and
the advised size.
Choosing where to place a tip is a difficult problem.
If placed in the body element, the tip have to be repositionned on each
scroll event which is performance-consuming and induces bugs (firefox
scroll event, tips which is over an element while the anchor is under,
...).
If placed in the anchor parent which scrolls, all the above problems
are solved but when the tip opens it cannot overflow its parent
boundaries, which is not possible in many contexts (modals, ...).
The solution here is to change the tip location when it opens/closes.
When closed, it is placed in the anchor parent which scrolls. This
allows to not have to reposition the tip on each scroll. The tip is
also naturally hidden when its anchor is not visible on the screen.
When opened, the tip is placed in the body, where it can be placed
on the top of anything in the DOM.
The transition from one state to another is not noticable as the
position does not have to be computed when the tip is moved in the
DOM and the animation is purely CSS.
Note: however, this commit does not solve the firefox bug of closing
the tip when the window scrolls. Here, the temporary solution is to
let the tip be wrongly position if the user scrolls when a tip is
opened (this only occurs when using the mouse wheel anyway).
Before being positionned, the tip is at the end of the body, thus
adding a scrollbar... which prevents to calculate the correct x
position of the tip.
The chosen solution is to place the tip at the center of the screen
in LESS before the first positionning. This also prevents the content
to overflow the body and does not break animation of the tip as its
display property is always block.
Most users don't care about this and find it confusing that on their
receipt they end up with the word 'Stock' (default stock location name).
Fixes#11733
commit 69d4aa363b replaces show()/hide() by classname o_hidden
but the folded submenus were still hidden using .hide()
thus they always remained invisible.
This commit fixes the action target="fullscreen" in community, where
the submenu on the left would sometimes remain visible.
The fullscreen feature was added in commit : d65d251c57
If the depreciation is not prorata temporis, the start date is defined
as:
- 1st of purchase month if frequency is < 12 month
- 1st of January instead
opw-681564
When a purchase requisition is created from a procurement, the
subsequent stock moves (create from the PO lines) are not linked to the
original procurement/stock moves.
This is an issue in the following use case:
- Product "Assembly" configured in MTO and manufactured
- Product "Part" configured in MTO and bought from suppliers thanks to
purchase requisitions
- A BoM is created for "Assembly" and is build from "Part"
When "Assembly" is sold, a MO is created, which generated a purchase
requisition for "Part". The MO is in state "Awaiting for Raw Materials"
since we need to purchase the components.
However, when the components are purchased and received, the MO stays in
the same state since there is not link between the stock move received
from the PO and the stock move created for the MO. The MO is therefore
stuck in "Awaiting for Raw Materials" state.
The fix is to keep track of the original procurement and stock moves.
Ideally, we should link the procurement to the PO lines, but that is not
possible since the field `purchase_line_id` on the procurement is a
Many2one. Therefore, we need to hook the confirmation process and
manually link the stock moves related to the PO to the stock moves
related to the MO.
opw-681138
Martin Trigaux