Another fix should probably be build for purchase price, but it isn't that easy, we need to know the partner to which the product has been purchased, as taxes are partner/country dependent.
Besides, included taxes in purchase prices happen less often.
In the new api an empty recordset converted to string is the name its class
while previously it was converted to an empty string.
The valid v7 condition sould have probably been
move.picking_id and move.picking_id.name or False
but in v8, simply move.picking_id.name is enough and avoids getting these
accounting entries strangly named when there is no picking.
If a wizard is launched from an embedded view list, only the record of the line from which the wizard was launched is reloaded after closing the wizard.
In this specific case, as new lines are added to the picking, we need to fully reload the stock picking
on_change_user was used to assign the first team in which the user is a member to the lead
When the user does not use the multi sales team, it therefore set a default sales team, but invisible to the user.
Stages displayed in the kanban view are the lead sales team stages. In a non sales team env, only stages with no stages are displayed for new leads
If you added a new stage, in the kanban view, the stage is not assigned to a team
The above revision, which was already a patch for rev. a8f94a59cd, did not work properly for modals, like the use template many2one field of the mail.compose.message wizard.
We therefore append the ui-menu selection nearer to the input field.
$el.parent().parent() looks odd, but the goal is to append this selection ui just after the parent of the field, but as jquery ui autocomplete only accepts appendTo (and not after()), we append it to the parent of the field parent.
This fix has been verified for
* many2one fields in classic form view (with or without sheets)
* many2one fields in editable list view (embedded in form view or not-
* many2one fields in wizard modals
* many2one fields of the bank statement reconciliation widget
The account_get method has the signature
def account_get(self,... company_id=None, context=None)
so should use positional argument context=context.
Added missing company_id parameter.
Fixes#4084
Follows 31a01ea, propagation of some fields from sales orders to invoices (when
created on deliveries) have been added but it missed the section_id field (Sales Team).
Fixes#4155
Some views are not appended to the element oe_view_manager_body, such as client actions views.
For these cases, we append the element to the view manager element
Besides, we set the appendTo option of jquery ui autocomplete after a first initialization, because of a Jquery ui bug:
http://bugs.jqueryui.com/ticket/8858
When composing an email based on an email template, some parts of the template
(the result of name_get on fields) were not translated.
This was due to missing language in context when rendering the template.
Fixes#3708, opw 617309
When a warehouse user transfer an incoming shipment, the linked purchase order
is updated as well but the user may not have access to it.
Trigger the workflow as admin instead. opw 619775
The `default_order` attribute of a <kanban> view was applied
for a non-grouped kanban view, but was simply ignored when
the kanban view was grouped, a common situation.
When a groupby is active, the main order is the column being
grouped, but the `default_order` is still useful as
a secondary sort ordering, within the kanban columns.
This patch complements the original patch of
rev. 5c0804eaef from PR #520.
Add restriction on product_id field to prevent the suppression of the product
if already present in an invoice.
This is to avoid the suppression of a used product variant when modifying
the list of attributes.#
Due to the constrain, the variant will be disabled instead of deleted.
Fixes#4129
Add warning message on the product form to warn users about the potential impact
of modifying variants.
Pricelist computations need to consider 2 different Units
of Measure:
- The default product UoM (product.uom_id), used as reference
for the various quantities and amounts specified in each
pricelist rules.
- The `context UoM` is the UoM in which the result is requested,
that is the list price UoM.
For example the 'price_min_margin' amount is meant for the unit
price of 1 x default UoM. When the context UoM is not the default
product UoM, it can be any UoM of the same UoM Category, and the
various quantities and amounts specified on the rule need to
be adapted accordingly:
- min_quantity (expressed in terms of the default UoM)
- price_surcharge (specified for 1 x default UoM)
- price_min_margin (specified for 1 x default UoM)
- price_max_margin (specified for 1 x default UoM)
The UoM corrections were not done consistently and resulted in
wrong prices when computing the price using a non-default UoM.
The cases were a conversion was needed or not were not properly
identified within the _price_rule_get_multi().
After this commit, the various code branches in _price_rule_get_multi
always ensures that:
- price requested for: `qty` of `qty_uom_id`
- `qty_in_product_uom` is the requested `qty` converted to default UoM
- current (intermediary) price: `price` for `price_uom_id`
Therefore `price` and `price_uom_id` are always in sync, and `price_uom_id`
can always be compared with `qty_uom_id' in order to know whether
a conversion is still needed.
This patch also corrects and extends the regression tests
introduced at revision 79ebe10.
With 'Fixed Price' enabled, a button giving the possibility to list all sale orders appears.
When browsing the list, there the possibility to create a new sale order.
The contract pricelist should be used by default when coming from this specific button.
When sending a message with the "Compose new message" button on the right of the user menu, in the top bar, if you tried to save the message as template, you had a traceback because model field of email.template is mandatory, but was set to True because there is no model in such a case.
As there is no any relevant model in such a place, and that the field is mandatory, mail.message is pretty convenient as the default value.
If the many2one selection height was too big (bigger than the browser page), it wasn't possible to see all options, because the body is set as overflow: hidden;
Moreover, if you opened a many2one selection and then scrolled the page, the selection moved with the scrolling, while it should be sticked to its input field
Potentialy, the timezone too.
On item action click (such as menus in More.. and Print..), the data in form view had the priority on user context (through the sidebar_eval_context)
Therefore, if a field "lang" was present in the form view (like in partner form), the web/action/load xmlrpc call was using the partner language instead of the user language.
Example of wrong use case before the fix:
- Set the user language in French, then go to a partner form of a partner with English set as language
- Click on any button of the partner form, such as the "Invoices" button, notice that the last item of the breadcrumb is in English, instead of Frenh (the user language)
- Click on any menu opening a wizard in the More.. dropdown menu, notice that the wizard title is in English instead of French
- Print any report from the Print dropdown menu, notice that the report file name is in English. If you print the same report for the same partner but from the list view, the report file name is in French.
website_customer filters the partners based on assigned_partner_id (the list of
customers that were impletemented by another partner). This field was not
visible so no way to actually display a partner in this list.
Fixes#430, opw 619254
On ecommerce checkout, the language of the partner wasn't set according to the language in which he is visiting the website.
Therefore, its partner was set with the default language (English in most cases), and any emails sent to him were not translated in his own language (in the email templates, such as the quotation email he received on order confirmation)
The key 'novalidate' is added in the context when an operation not impacting
the validation of a move is made. The validation recreates analytic lines
which decrease the performances.
In case of registrating a payment, the skipped validation are the one from
the reconcile method (reconciliation does not change the validity)
Fixes#3787, opw 618529
The destruction of one2many fields is forced with the event change:effective_readonly
This revision add the forced destruction for cancel(discard) button as well
Otherwise, one2many fields are not properly destroyed when hitting the button "discard" (from save or discard).
This can be problematic for one2many editable list views (such as invoice lines) if you discard while having a mandatory field not filled in the invoice line: You can't recreate an invoice, the one2many editable list is messed up
Use case: Create an invoice, create a line, leave the description, required field, empty. Then, discard. Then, click on create.
opw-616946
This is possible to set field conditional defaults, if the field has the attribute "change_default".
The defaults are set by the web client, by calling the method "get_defaults" of ir.values model, when the onchange is triggered on the field on which the condition is.
In 7.0, all onchanges were triggered clientside, one by one. On creation, the defaults of default_get method were pushed in the form, and then, as the values of the fields were changed (from null to the default value), all onchanges on which there was default value were triggered.
In 8.0, onchanges are performed server side, all at once. On creation, the onchange method is triggered by default (wether or not there is a default value for them), for all fields (widget param of method do_onchange of view_forms js is undefined, meaning the onchange is not triggered on a specific field, but on all fields). In such a case, we must call the get_defaults method of ir.values model for all fields (having change_default attribute), in order the conditional defaults to be set in the form view.
For selection fields, name_get calls to resolve the display name are client-side initiated, and will display "Unknown" if the user does not have read access to the selected company. And the reason for using a selection widget in the first place was to prevent inadvertent creation of companies. This is now doable via the no_create option, so we can remove the selection widget.
product_id_change_with_wh onchange was not anymore called when using the popup form in sale order line.
The behavior was different concerning the product onchange when being in the editable list or in the popup form
For instance, for make to stock products not having enough stock, the warning was displayed when being in editable list, but not in the popup form
This is a regression of rev. 86f785ae1b
opw-619624
The warehouse name and address name is often the same (name of the company).
Remove the name of the address as two warehouse may use the same address.
Fixes#4062
The price_total field of the account invoice report is not rounded (it cannot be easily rounded, as this has to be done in the sql view)
In a multi currencies environment, this is possible that the price_total value has a lot of digits
We therefore round it manually, for the gauge of the sales team kanban view
Add invoicing related fields on anlytic account tree view for the invoicing group only
Otherwise, when a user not having the invoicing access rights displays the analytic account list, he gets an access right error.
opw-619485
This reverts commit 5f9280e854.
These tests have been introduced in 7.0/saas-3, but can no longer be applied in 8.0, as they uses models that do not exist anymore in the new wms.
if such tests do not exist yet in Odoo 8.0, then these tests needs re-work, they cannot be applied like that
Conflicts:
addons/purchase/tests/test_average_price.py
Pass group_id information when a manufacturing order is created from
a procurement to keep a better traceability and know the reason of stock.move
creation.
Fixes#4019
Without this better floating point handling, an extra stock move might
be created for zero quantity for some order lines upon PO confirmation,
because qty is equal to something closer to e.g 1.14e-13, but this is
larger than 0, so it creates a stock.move, which gets rounded too late
to 0.0
Closes#3346
Fixes comparison with min_quantity orderpoint in scheduler - basic floating
point math issue in procurement scheduler when comparing current quantity
with orderpoint minimum quantity. In certain cases floating point comparison
could result in e.g 400.0 < 400.0 == True due to typical floating point
comparison issues, as Odoo doesn't use Decimal types where the issue
doesn't exist.
Fixes early exiting out of the loop cycle, in case qty is already near zero.
Fixes the new procurement creation check, to not do that if it's close
enough to zero already, to be considered a floating point math error, not
really non-zero.
These combined (or at least the last one) avoid each supply_method == buy
pending in draft PO's getting a zero quantity extra procurement order each
time the scheduler runs. Otherwise there could be hundreds of zero quantity
procurement orders pending, which makes the confirming of the PO take hours,
due to creating hundreds of stock moves for each order line.
Use float_compare helper to solve all these with floating point type for now,
instead of the more evasion possibility of converting to Decimal module.
Two potential bad comparisons remain, add FIXME notes for now until further
analysis.
Also: Float rounding on reste when comparing and on the procurement qty
When the list view is grouped, the page count should be hidden as irrelevant.
However if it's fully hidden, the limit can no longer be changed.
Instead of hidding the pager, this commit hides the arrows and replaces
the content by the current limit to allow to be changed.
The average price computation is now deduplicated and moved to
a separate function called in stock_move action_done.
This makes sure it is always called when a stock.move is
processed, even without going through the partial picking wizard.
Fixes#2991Closes#3949
OPW-615491
The same is done when extra moves are generated. It is going to check if the UoM of the operation is smaller if it has one.
Throw an error when a key can not be found in action_done because there were links on a move
that was not supposed to be done (e.g. 0.5 Dozen when Dozen is rounded at 1)
[IMP] Throw an error when a key can not be found because of UoMs/picking + extra float_compare
[IMP] Integrate remarks qdp
[FIX] Remaining qty should each time be in the default UoM of the product
Even with different UoM we want a consistent matching between moves and pack operations.
When calculating the remaining qty on move/pack operation we always start by converting the
qty on the move/operation to the default UoM and afterwards we subtract the links between them
which will also be in the default UoM of the product.
In order to create backorders / extra moves these quantities are used.
When a negative quant is created but the positive quant counterpart is reconciling
a negative quant that of course also has a positive counterpart, the latter should eventually
let its field propagated_from_id tell that it originated from the very first negative quant as the
second negative quant will have disappeared through reconciliation.