Commit d349584 solved the state change tracking of pickings, and
moreover prevents unnecessary state changes to be recorded. However,
this also prevents the state "Done" to be recorded in the chatter.
Saving properly the state change for the picking might be quite tricky,
since the stock processes sometimes imply unreservation/rereservation of
quants, and therefore lead to several state changes inside the same
process.
opw-680343
fields ref, journal_id and date on account.move.line are all related fields on
the account.move.
Setting a value here is then useless and triggers write on the account.move
after the creation of the account.move.line (inverse values in write)
Function fields, old-api style, that are not stored do not have cache
invalidation mechanisms. This means that they are recomputed every time the
field is accessed.
Due to the way the cache behaves, the records that are present in the cache will
be included when the prefetching is done.
In the scenario of the a POS session being closed, this implies that the cache
will contains more and more account.move.line records and try to prefetch all
(hopefully max 1000) without ever relying on the computed result for the next
access. This makes the computation of fields `amount_total` and `price_subtotal`
very slow, even for orders with a very low number of lines.
Backport the new API migration of these computed field to benefit from depends
mechanism and keep the computed value into cache when needed.
In master these fields should be stored.
On the other routes (e.g. /my/, /my/contract/) payment information on the parent
contact are displayed but can not be access in the my payment route.
You get in a unconsistant situation where you can access the contract of the
company and its payment information but can not use this payment information.
opw-681491, opw-681502
An access error occurs when a the delivery address of a SO is set to a
different partner than the SO partner. In this case, the picking
created is associated to the partner of the delivery address. This is an
issue when the SO partner tries to view the picking from the front-end
("My Account"), since he is not allowed to access it.
opw-681341
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
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
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.
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
This reverts commit f38f8930f0.
Revert for internal choice. Odoo want to use qweb in template and remove jinja support on next version.
If users want to use jinja they can change the view to use text widget instead of html widget.
Before this revision, it wasn't possible to invite new users
(in the Settings Dashboard) multiple times without reloading
the dashboard
e.g. Invite one user, then fill again the textarea, and click
again the `Invite` button
This is because a new widget is created at each reload,
because of:
```
load_invitations: function(data){
return new DashboardInvitations(this, data.users_info).replace(this.$('.o_web_settings_dashboard_invitations'));
},
```
and
```
reload:function(){
return this.parent.load(['invitations']);
},
```
and `this.$('#user_emails').val().` is empty at the second reload,
because the textarea retrieved with this selector is the textarea
of the previous widget, which is now empty.
It should probably be proper to make another mechanism for the reload,
that doesn't create a new widget each time,
but we don't take the chances in a stable release. Therefore,
we just use the event delegate target to retrieve the right
textarea.
opw-677680
When processing the delivery order coming from a sale order,
the delivery line must be created as sudo, as the user
processing the picking could not have the access rights
to create the extra line on the sale order
(e.g. for users being inventory users but not sales
users).
opw-677628
When an pos session is created, a bank statement is created and
it must be linked to the pos session.
A pos user doesn't have the rights to write and read on a bank statement.
This is why the creation of the pos session and the creation of bank statement
have to be done as super user.
opw:678970
When going to routes ['/my', '/my/home'], only the project issues in
portal privacy visibility must be displayed.
Inpired from 56c5d0a
The field privacy_visibility is not accessible in portal due to access
rights.
opw:676447
For `this.viewmanager.active_view` to be set, the view manager
switch mode must be completed, meaning the deferred returned by
the function `switch_mode` must be resolved
(see `this.active_view = view;` in `view_manager.js`, line 146)
In a 2many field, the view manager `switch_mode` deferred is resolved
when `is_loaded` of this field is as well resolved.
Before this revision, clicking fast on Save then Edit
of a vendor bills resulted to a JS error due to a race condition,
because `this.viewmanager.active_view` was undefined when
the field was not loaded / the view manager switch mode not completed.
opw-678097
The preview change the content because the browser try to fix the dom.
If a user use jinja and activate the preview, the jinja code is (re)moved by the browser and broke the template.
Consider fields G1 and G2 being computed fields with inverse methods that
require the value of a common dependency F, which is also a computed field.
For inversing G1 and G2, their values are put in cache, then their inverse
method is called. If the inverse method of G1 requires the computation of F,
setting F's value will invalidate both G1 and G2 in cache. Hence the value of
G2 is lost when invoking its inverse method!
The fix consists in marking G1 and G2 as being computed before invoking their
inverse method, which prevents them from being invalidated by field F.
DO NOT FORWARDPORT!
If a purchase pricelist depends on the supplier price, the purchase
price in a PO automatically from procurements will be zero.
It was (partially) working before 7613cb3 by luck since the price of the
first supplier was chosen by default if no supplier was found. In fact,
the condition `seller_id.name.id != partner` requires the `partner` to
be an ID, not a browse record.
opw-681105
Some users using community version of Odoo may understand that this module turns
the POS into a certified module (which is what pos_blackbox_be does).
Update base.pot to reflect the changes (and add other missing translations)
The order of BOMs is based on the sequence which is
not present in the view. When you open all
BOMs, any order is defined. This patch will display the
list of BOM by product.
opw:681189
float_is_zero(value1-value2) is not equivalent to
float_compare(value1,value2) == 0, as the former will round after
computing the difference, while the latter will round before
opw:678588
When the mail composer is opened thanks to the "Send Mail" button in
Discuss, it's possible to save a mail template, but the user can't
access it anymore later on.
This is because the field `model` is by default empty in this specific
case since this is a client action. However, when saving the template,
the default value 'mail.template' is used for the `model` field.
Therefore the domain on the `template_id` field prevents the user to
find back the model he just saved.
The fix sends the `active_model` in the context with the value
'mail.message', so that the `default_get` method of
`mail.compose.message` will set the appropriate default value.
opw-677936
Adrien Dieudonne