Before this commit, when clicking on an image which is in a link, both
the link edition dialog and the image edition dialog were opened. Now
only one opens.
PURPOSE
=======
By default the list view of LN/SN should be group by products which is more readable for end user.
SPECIFICATION
=============
Default group by product on lot/serial number list view
PURPOSE
=======
Clean menus in manufacturing
SPECIFICATION
=============
* Operations > Orders
* Scrap > Scrap Orders
* Bill of materials > Bills of materials # bistray
* Move the menu "Work Order Messages" in Master Data
* Remove menu "Planning" if WO or MPS no active
* Menu "Orders to plan" > visible only if WO active
* Menu "Waiting for material availability" > visible only if WO active, put it above "Orders to plan"
* Master Data, order of submenus : Products / BOM / Routings / Work Centers
PURPOSE
=======
confusing tooltip on "Alert Date".
SPECIFICATION
=============
Replace the tooltip on alert date by : "Date used to determined what are the expired lots and serial numbers using the filter "Expiration Alerts".
PURPOSE
=======
Improve empty list messages of the MRP application
SPECIFICATION
=============
* Manufacturing Orders
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZreG5WM3IyV29QaDg/view?usp=drivesdk
Expected :
Click here to create a Manufacturing Order.
Based on a Bill of Material, a Manufacturing Order will consume raw materials and produce finished products.
Manufacturing Orders can be generated automatically based on customer requirements or reordering rules.
* Work Centers Dashboard
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3Zra21mUWZoQ3VhcG8/view?usp=drivesdk
Expected :
Click here [add a link to work centers list view] to create a new Work Center.
Manufacturing operations are processed at Work Centers. A Work Center can be composed of workers and/or machines, they are used for
costing, scheduling, capacity planning, etc. The Work Centers are defined on the Routing's operations.
* Work Centers
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrbGZocVc1TXd6dUE/view?usp=drivesdk
Expected :
Click here to create a new Work Center.
Manufacturing operations are processed at Work Centers. A Work Center can be composed of workers and/or machines, they are used for
costing, scheduling, capacity planning, etc. The Work Centers are defined on the Routing's operations.
* Work Orders
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrSmpCU1pOaWpEQWc/view?usp=drivesdk
Expected :
Work Orders are operations to be processed at a Work Center to realize a Manufacturing Order. Work Orders are trigerred by Manufacturing Orders, they are based on the Routing defined on these ones.
* Unbuild Orders
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrUmpoN2ZzM2prazg/view?usp=drivesdk
Expected :
Click here to create a Unbuild Order.
Unbuild Orders are used to break down a product you manufactured or purchased into its components, based on its Bill of Material.
* Scrap Orders
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrZl9QdWRNZXRTTWc/view?usp=drivesdk
Expected :
Click here to scrap products.
Scrapping a product will remove it from your stock. The product will end up in a scrap location that can be used for reporting purpose.
* Work Order Messages
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrSWZocUU1MkwxRjg/view?usp=drivesdk
Expected :
Click here to create a new Work Order Message.
Work Order Messages are used to warn users about any change in the product, process, etc.
These messages will appear on the involved Work Orders.
* Routings
Current : https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrNE1FNFNXYWJWSzA/view?usp=drivesdk
Expected :
Click here to create a new Routing.
Routings define the successive operations that need to be done to realize a Manufacturing Order.
Each operation from a Routing is done at a specific Work Center and has a specific duration.
PURPOSE
=======
The status "Bills received" on the PO simply means that there are no bills to receive for now, not that you have really received bills. This is confusing for users.
SPECIFICATION
=============
Replace the invoice status string on PO "Bills received" by "No Bill to Receive"
This test do not simply depend on company's currency; it also depends on
installed pricelists and taxes... It is safer to run it after the
installation of all these modules, else you can observe different result
depending on the modules installation order.
PURPOSE
=======
In the payment options there are 3 radio buttons given , but as per the normal behavior of radio, there must be one selected by default.
Commit 57b8b9a057 changed templates used in recruitment. However we try
to stick on using the main model name when naming templates. Templates
subject may be whatever you want but templates should use main model as
name to order them and ease their use.
Account demo data try to add lines to payment terms. However when
reinitializing the module similar lines are added and a constraint
raises as there should not have duplicates. This commit voids
payment terms before refilling them.
Before this commit, it was not possible to reach the general settings when one
of the "default" provider was delete.
After this commit, we don't assume anymore that there are google and facebook
providers.
opw-746907
In a SO, the "Invoiced Qty" can decrease if the refund is generated from
the SO. It doesn't decrease if the refund is generated from the Invoice.
However, we don't have this mechanism in a PO since the invoice is not
generated directly from the PO. There is therefore no way to decrease
the "Billed Qty".
We authorize the "Billed Qty" to decrease in the case of PO.
Backport of c6a7e4fbb9Closes#17564
opw-747038
When an expense sheet contains several expenses with various currencies,
some issues arise:
- the currency is not specified in the form view
- the report mixes the currencies
- the total amount doesn't make any sense
Fixes#17341
opw-745714
Website content is not supposed to use flex as it is not supported by
some old browsers. This commit provides a way to use flex only for
browsers which support it. When designing a snippet, you can use flex
to design elements and then write other style for when flex is not
supported.
Using flex should however still be avoided when possible. But hopefully,
this commit will allow to build greater snippets whose ugly non-flex
style can be disabled on demand or dropped in a future odoo version.
When creating an account.payment via the form view, an onchange sets the
partner_type based on the payment_type (which has a contextual default)
and the field is view-required.
When importing however if the user does not specify a partner_type
(which they are not specifically told about) the payments will be
created with no partner_type and thus classified as "internal payments"
and will not appear in either the Sales > Payments or the Purchases >
Payments, confusing them and making them think the import has failed
despite having correctly validated and raised no errors.
Add a default_partner_type matching each action's domain (and default_payment_type) such that the imported payments are correctly classified by default.
OPW-746479
fixes#17388closes#17497
It shouldn't be possible to duplicate ir.model.fields. Add attribute
´duplicate´ which can be set to false to hide the duplication option in the
action menu.
website_sale_digital overrides a method defined on
website_portal_sale, but only depends on website_portal and extends
the base controller from website_portal. Depending on the (relative)
order in which the system decides to load website_sale_digital and
website_portal_sale we can end up with the former's template but the
latter's methods (without the proper context data). Which ends up
commonly crashing in P35.
Fix dependencies and controller inheritance.
test_00_sale_stock_invoice would blow up in Python 3, because the
test(s) relies on the iteration order of the products dict to know
where which line is (holy mother of caca) an set the relevant line's
data by indexing directly into it.
This would fail (with very odd results) in Python 2 and 3 as it could
set information on the "wrong" order line aka the order line for a
different product (and invoicing mode/whatever) than intended.
Fix the issue by hard-coding the products iteration order (to the
iteration order I get in Python 2.7.10 on that dict literal) using an
OrderedDict.
- Create a stockable and a service product
- In the POS, sell 1 unit of the stockable product and -1 unit of the
service product
- Validate and pay
2 pickings are created: a picking containing the stockable product which
stays in state 'Draft' and an empty picking in state 'Available'.
The problem comes from the negative quantity on a service product: we
should filter out services when checking the quantities.
opw-745712
dbh