With the new views, the merge task feature did not properly precomplete the selected tasks. This is because they do not support the command 4 when creating a new record. This will be fixed at some point, but meanwhile, we can just simply return the selected ids in the default_get. This makes the code slightly simpler.
(PR #17566, issue 746867)
Before this commit, the return flow in the pos would not work if closing the pos session intervened before the return payment registration.
The balance of the the statements was not updated before going to the validate step.
After this commit, we force the recomputing of the relevant fields (i.e. balance_end_real), to reflect reality and permitting validatioon afterwards
Backport of e27a3b185e (on #17438)
Closes#17599
OPW 743763
Steps to reproduce the bug:
-create a child contact of a company C
-invite the child contact as a portal user
-sign into the website and place an order w/ wire transfer as payment acquirer
Bug:
The payment term set on the quotation was not taken from the company C and
the default sales person was not taken from company C too.
opw:745091
Before this commit, the return flow in the pos would not work if closing the pos session intervened before the return payment registration.
The balance of the the statements was not updated before going to the validate step.
After this commit, we force the recomputing of the relevant fields (i.e. balance_end_real), to reflect reality and permitting validatioon afterwards
OPW 743763
Closes#17438
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
Issue: when using `copy` in a given lang, the value of XML/HTML fields is
copied in its translated form, making existing translations useless. Fix the
value of such fields by storing their original value instead.
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.
When doing a delete, the cache is cleared, putting an unlink in a loop
multiplies the number of requests made (for access rules, relational
field, recompute ...) by the number of rows. Doing it outside the loop
speeds up the validation of the invoice.
Backport of 10.0's 2687571781
When the user duplicated a record 'A', and deleted the new record
'A (copy)' directly, the wrong record was deleted: 'A' was deleted
instead of 'A (copy)', because de id of 'A' was bound to the delete
handler, and it wasn't updated after the duplication.
Also correctly updates the record's offset after the deletion, so
that it doesn't produce a warning when deleting the last record of
the dataset.
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"
Purpose
=======
in an empty db, when creating manually a user, there is some noise on the form
Specification
=============
- Rename application into "Application Accesses"
- Remove the button to change password, just keep the action, normally, you don't have to do that.
When doing a delete, the cache is cleaned, putting an unlink in a loop
multiply the number of requests made (for access rules, relational
field, recompute ...) by the number of rows. The use of a mapped improves
the speed of validation of an invoice.
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.
- Activate multi-currency
- Define a rate today (e.g. 2017-06-01) and next month (e.g. 2017-07-01)
- Create a deferred revenue on 2017-07-02 in the foreign currency
- Post the first line
The rate taken is the rate of today, not the rate of next month.
opw-745509
Empty forward-port because commit 21f93b8035
is only a backport that does not need to be forward-ported again.
The point of this fwd-port was to resolve the conflicts immediately.
Low-level methods have to convert datetime into a naive user timezone
in order to match the attendances and leaves. Returned values are already
in UTC ready for display. Therefore no postprocessing is necessary for
output.
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
Manual forward port of 577eb10c0b .
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.
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
When printing the sales details of the day in the point of sale interface,
The orders printed were the orders of the UTC day, not the orders
of the day within the user timezone.
opw-745273
'id' is a particular field that should not be considered like other
integer fields. For instance, in the evalContext, its value should
not fallback to 0 if it is false. This would break domains in attrs
like ['id', '=', False], which is supposed to be true on new (not
saved yet) records.
This was for example the case in the Product form view: go to Sales
Orders form view, add a line, on the product field choose 'Create
and Edit', try to save the product -> error: field Product Template
is required but not set (actually it is invisible), as its required
modifier says ['id', '!=', False], which was always the case.
Ultimately, it seems that sending the value of readonly fields
when saving is not such a good idea. Suppose that there is a
computed field displayed as readonly in a form view. This field is
computed from other records, e.g. from a one2many field which is
editable in the form view. Finally, the inverse function of the
computed field creates the one2many records. If the user adds some
records to the one2many, then saves, the readonly computed field's
value is sent to the server as well, and thus the inverse function
is executed, which isn't what we want.
This commit essentially reverts 0494d61274, except that we now take
into account the readonly modifier to determine whether or not a
value is sent to the server, and not only the readonly attribute of
the field (which can be seen as a default). Before rev. 0494d61274,
we made a difference between write and create RPCs, for an unclear
reason. We don't do that anymore: readonly fields are never sent to
the server (same behavior as before the new views).
A problem occured with a required Many2One inside an X2Many (e.g.
order_line field in sale.order form view). If the user clicked on
'Add an item' to add a row, then typed some text in the Many2One,
then clicked on 'Create ...' to quick create a new product, and
then directly clicked on 'Add an item' to add another row (before
the name_create returned), the first row was discarded.
This was because before the name_create returns, the Many2one still
has no value, and as it is required, the row was considered invalid
and then discarded.
This rev. ensures to wait for the name_create to return before
trying to save the row and to create a new one.
Darshan Kalola