[9.0][BUG] Fixed inconsistent UoM domain in Quotations/Order #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[FIX] packaging: debian: update-python-module is no more The command is not installed by default. It was available in the python-support library which we didn't depend on and now this library is no more in debian jessie/ubuntu xenial. Backported for #13302
In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order will generate unexpected behaviour. Eg: > id id_dept name > ------------------- > 1 1 Tom > 2 1 Mike > 3 2 Meggie > 4 2 Marge > 5 3 Bart > 6 3 Lisa > using LIMITed selects like: > SELECT * FROM employee ORDER BY id_dept LIMIT 3 > SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3 > SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6 > You can have some result missings from the 3 requests, and others duplicated. > Because id_dept is not a uniq order. opw-686639 note: backport of saas-12 4dce861
An entry with EXTXVAL=0 should not be included in the Intrastat declaration, otherwise it is rejected. opw-686201
- Activate the option "Track Lots or Serial Numbers". - Set the outgoing process as 3-step one. - Create a stockable product for which the tracking is "By Unique Serial Number". - Go to Sales > Sales > Sales Orders. - Create a Quotation for the created product and confirm it. A picking is generated but it is waiting availability. - You are sure to have this product in stock so you force the availability and assign the serial number (001) you want to transfer in the operation lot details. - Validate the picking. By doing this, it creates a negative quant in the origin location (WH/Stock) and it creates a positive quant in the destination location (WH/Packing Zone). The two quants are linked to each other. - Go to Inventory > Inventory Control > Inventory Adjustments. - Create an inventory in WH/Stock for all products and set it in progress. - You want to correct the negative quantity you have so set the real quantity of product B to 0. - Validate the inventory and you get the following warning: "The serial number 001 is already in stock.Otherwise make sure the right stock/owner is set". We should allow a quantity larger than 1.0 temporary, so it allows the system to reconcile the quants. opw-685825
When anglo-saxon accounting is enabled and the valuation of a product is 'real_time', rounding errors might occur in the price difference between the invoice price and the product price. It occurs when the product price precision is larger than the accounting precision. To avoid these rounding errors, we calculate the difference as the difference between the price before update and the price after update. opw-686730
When a database is created, we are not auto-logged in to the new database anymore because the login passed to the authentication request is 'admin' instead of the one set in the creation form. To fix this issue, we used the login parameter from the creation form in the authentication request. We also set the login field to required in the create database form view. This bug comes from rev 903733a32
When removing the "Save as Attachment Prefix" field of the Invoice report (`account.report_invoice`), it was no longer possible to reset the invoice to draft opw-687130
When a product is returned after receiving, the return picking doesn't appear in the corresponding PO. opw-686895
When the statusbar is clicked, a `debounce` function prevents a doucle-click, and therefore making several `write` calls. On some status bars, clicking doesn't work anymore. The reason is because, in some mysterious cases, the event is propagated to the parent. The `currentTarget` is not the `li` element, but the parent `ul`. By setting the `immediate` argument to `true` (execute the first function instead of the last), this solves the issue.
…aluation. OPW: 684742 When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687. The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line). That means that: * If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation. * users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
…petual valuation." This reverts commit a57b10d. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
Since commit 2ab6804, the Paypal link can be sent in an invoice as it was the case before. However, in order to be able to save the Paypal account in the accounting settings, the Paypal account must be website-published. If the module `website_payments` is not installed, this is not possible. We remove this condition, since it should be possible tu use the Paypal payment method without installing the whole website. opw-686216
When the statusbar is clicked, a `debounce` function prevents a doucle-click, and therefore making several `write` calls. In debug mode, the click doesn't work anymore. For some mysterious reason, the event is propagated to the parent. The `currentTarget` is not the `li` element, but the parent `ul`. By setting the `immediate` argument to `true` (execute the first function instead of the last), this solves the issue.
…with perpetual valuation. OPW: 684742 When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687. The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line). That means that: * If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation. * users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
…erpetual valuation. OPW: 684742 When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687. The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line). That means that: * If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation. * users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves). This is a forward-port/cherry-pick of 7bdd4de
When a model has no form defined, a default view is generated displaying all fields of the model. The one2many and many2many fields were not displayed on the form, probably for aesthetic or historical (2008) reasons.
When consuming products tracked by unique serial number, no check is done on the quantity consumed for a given serial number. It means that negative quants might be created without any warning to the user. We implement a simple warning thanks to a onchange. opw-687129
From Odoo 9.0, en_US is not always activated in Odoo. As a fallback, if the search for a language does not find company language nor English US, we use the first available language (there is always at least one). In order to reproduce this behavior, eg: you can set the language of your company's partner to en_US, then load another language, then disable en_US from your database. Try to open the "Accounting" dashboard and you will get a traceback.
As provider model is intended to be used internally restricting the read of some private fields to the employee group avoid creating access issues.
Without the @api.multi property, the method is considered as taking only one parameter (self?), while it takes multiple parameters. This prevented to change the quote template on a sale order, if the quote template had some order lines, due to the below error `TypeError: product_id_change() takes exactly 1 argument (19 given)` opw-687797
In some cases, users change the sequence of base views in order to have one applied before the other e.g. when there is two inherited views doing ``` <tree position="inside"> ... </tree> ``` The priority of the views will have an impact on the fields order in the tree. On update, the change of priority done by the users was overwritten, even if the priority of the view was not defined in the XML code of the view. The priority of the views should be overwritten only in the case were the priority of the view is specifically set in its definition. opw-688470
When a stock.pack.operation gets created by a stock.picking, it will have its pack_lot_ids set. This way the user has an overview of what lots are available and how many of each are still left. When splitting the stock.pack.operation these where lost. The still unpacked stock.pack.operation would always have an empty pack_lot_ids field. The reason for this is that those records where reassigned to the newly created and packed stock.pack.operation. This resolves the issue by copying pack_lot_ids that are still available (qty_todo > 0) and assigning them to the original stock.pack.operation. opw-685908
Analogous to 6fde72abeacdac6e36a0c623c024252839f993ae but now instead for the 'split' button. Additionally this uses float_compare with the rounding set on the uom of the operation to determine if there are any units left, which is more correct. opw-685908
Currently, when rendering a list view cell with a many2many we would empty the list of ids, and fill it again once a name_get is resolved. But in some instance, the code could use the data when it has been emptied out. For example, if we set the tax_id field (inside the order_line list view inside the sale.order form view) as requred, if we modify the order line and save directly (without clicking outside of the list view) we can get an incorrect error saying that the "Order Line" is not valid. It has been reproduced when saving with CTRL + SHIFT + S on google chrome and firefox, and there have been reports that for some configuration it also happen when clicking on the "Save" button. This commit change the behaviour so the value is kept whilst the name_get is ongoing, and just use a default "false" value for the name during this interval. closes #13478 opw-668067
According to RFC 7232 # 2.3, an etag must be wrapped in double quotes:
entity-tag = [ weak ] opaque-tag
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
Odoo didn't properly quote etags, which could lead to stripping or
failures when putting Odoo behind strict HTTP proxies.
An issue arises in the following use case: - Company rounding policy in "round globally" - Tax excluded of 20 % - Create a statement of 3.80 EUR - Reconcile the statement thanks to the reconciliation widget - Click on "Choose counterpart" in order to manually create a line to reconcile with the 3.80 EUR statement - Add an amount of 3.17 EUR, and choose the 20 % tax The widget creates an extra line of 0.00EUR . This is because the remaining amount is 0.004. The reason lies in the `monetaryIsZero` function. There is a hardcoded decimal precision of 4, while it should be 2 for EUR. We add an extra parameter to the function so it is possible to adjust the decimal precision required. Only the problematic calls are modified to avoid unnecessary intrusive modification. Closes #13452 opw-688399
When doing a reconciliation, make sure that the tax amount is properly rounded to the currency precision. Otherwise, if the rounding policy of the company is "round globally", the amount recorded won't be rounded. opw-688399 Closes #13452
…ived by the responsible only Currently some customers receive the automatic notification 'Quotation viewed by customer'. This should not be the case as this notifciation is purely internal and should only be sent to the quote responsible. Notification is now a note with the responsible being directly in the recipients. Conflicts: addons/website_quote/controllers/main.py Backport of 14f07cb opw-687957
orderpoint.lead_type should be 'supplier' instead of 'purchase' opw-687311 Closes #11389
When an onchange return a NewId for a many2one, the expected result is a False value. It appear for computed many2one that can return currently created record like `res.partner.commercial_partner_id` field.
The .dropdown is in a .btn-group environment while a .btn-group can only contain .btn or .btn-group elements. This induced problems where the m2o options covers the full overlay environment, preventing clicks on the customize dropdown.
The quantity event handler is not correctly unbound when its action
is deleted, resulting in multiple window.prompt asking the quantity
of the products if you go mulitple times trough a view when a widget
implementing the barcode thing is used.
There seems to be a bug in the framework ("barcode_scanned" events
are registered the same way than the "keypress" one on core.bus
but they don't have suffer from the same issue).
The dashboard instantiates an action manager for each view it has to display. It then replaces the do_action() function of those action managers by its own one, forgetting to pass the second argument 'options'. Thus, when do_action was called by a view of the dashboard (e.g. a button in a list view), it was called without the options.
When a pad is created programmatically (e.g. through a project task or a note), the pad is empty when it is first displayed. It is necessary to edit the record and save it in order to be able to see the content. This is because the pad is normally initialized by the JS layer, at the first edition, thanks to a call to `pad_generate_url`. Therefore, a programmatic pad creation won't initialize it. opw-685826
The checkbox was there to activate autoplay... but was not doing anything since the web_editor/website split.
name_get function needs to ensure that read passes the required ids as a list, not a single value. This is very important if the method is inherited.
Changes f -> FALSE and t -> TRUE, otherwise when installing the l10n_lu COA, the reconcile flag is wrong. Closes #13282 opw-688957
Tree view was removed to hide the different view types display in enterprise as it was "cleaner" for a dashboard. Re-adding for import button. Future versions will not display departments as dashboard but employees anyway.
This token will be added automatically at posting (by ajax.js from framework)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
33 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the issue/feature this PR addresses:
The product_uom field's domain in sale.order.line would be inconsistent and improper in several situations.
Current behavior before PR:
When adding a line to a quotation/order, the domain of the product_uom would be changed in the onchange function called by a changed product_id. This onchange function would change the domain on product_uom for ALL lines in the order.
Also, when editing the order, the product_uom would have no domain. The user would experience an inconsistent UI compared to when they created the lines.
Desired behavior after PR is merged:
The category for the product_uom's domain will always be properly defined. Each line will have an independent domain, and it will restrict the product_uom selection so that it can only be changed to UoM's in the same category as the existing UoM.
To solve these issues:
I Added a relative field for the category_id of product_uom, and stored it in the database.
I added this relative field to the view (invisible=1), and used it in the default domain for product_uom.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr