Global push/pull rules are error prone and can be replaced efficiently
by creating a "global" route.
There was an odd behavior when you delete a route, the different rules
of this route were'nt deleted and thus became global. A lot of users
didn't understand that, so to avoid this unexpected behaviour, we
delete on cascade the push and pull rules when a route is deleted.
To avoid inconsistencies in the system, we also restrict the deletion of
rules when they are used in a stock move or in a procurement. We also
restrict the deletion of routes used in warhouses and order lines.
We change the global pull rule test by applying the procurement rule on
a route and apply this route on a product.
Menu items related to global rules are removed, so are the logic to look
for them in the methods looking for which pull/push rule to apply.
joint work by @dpa-odoo, @pimodoo and @sle-odoo
- Only display the warehouse and location field when the user is working
with multi warehouses and multi locations.
- MRP defines a stock.picking.type on manufacturing order, so that you can
easily set the source/destination locations and benefit from seeing a
manufacturing vignette in the inventory dashboard. However, the
manufacturing orders do not use every options defined on this view,
specifically the return picking type, the barcode nomenclature and the
packs and lots. This commit hides these options when the vignette is an
MRP one (manufacturing code).
A cleaner patch would have been to adds attrs with an xpath from the MRP
module, but if another modules wants to add another vignette there will
be a problem, so we chose the easiest way here.
While creating a location, users were able to create a location when
chosing the parent location and it was error prone. We remove the
possibilty to create a location at this place.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
Tomorrow never dies; however no need to add its working hours today.
Indeed rrule until parameter is inclusive. This means that in
current implementation next day is included in computation. This commit
fixes that.
Backport of 1f6ec2b8d6
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
opw:708099
Resource module defines some demo data that are not used anywhere.
Moreover using resource module on its own does not give interesting
results as this is a tool module used in various addons like holidays
or project issue.
Those modules define their own demo data that will have an impact on
resource. It is therefore not necessary to define specific demo data
that does not help the user in any way.
Those fields are never used anywhere. Moreover attendance module can be
used to track employee log in / log out and compute its attendances.
Let us therefore remove those fields.
When you define recurring maintenance requests on an equipment, the
maintenance duration and the maintenance team is not set on the created
requests.
The problem comes from the creation method called by the cron that
doesn't use the duration and maintenance team to create new requests.
We now use these fields in the request creation
Before this commit, in the form view, if an attrs domain contained the
"id" field, it only worked if the "id" field was explicitely added to
this form view.
As the "id" is obviously known on a form view without the need to be
explicitely added, this commit allow using attrs domain containing "id"
in all form views.
Note: this seems to already work with list views.
The domain selector currently determined the list of available
operators according to field types (and used only a subset of
supported ones).
In some context, we might want to restrict this list of available
operators. Indeed, in client-evaluated domains, the "ilike" operator
cannot be used for example.
2 sequences are created when a pos.config is created:
- one for pos.order, stored in sequence_id field
- one for pos.order.line, link is lost, like dust in the wind ♫
When creating a pos.order.line from a new order, the default value was using the
first sequence if found using the code 'pos.order.line' (returning the latest
created).
The name of the line was always using the same sequence, whatever the config
used.
In master, the field has been stored at 645df676 but in stable version, the
following hack is done:
As the sequences are created in the same transaction as the pos.config, the
create_date will be the same to the microsecond.
The name of the config can not be used as too easily changed (e.g. duplicate)
and may not be unique.
Done in SQL to avoid ORM cleaning of microseconds, not working with a search.
opw-703092
The link between the pos.order.line sequence and the config was lost after
creation.
Using the default with next_by_code is incorrect as every pos.config has a
sequence with the same code.
With a sale order with:
- a stockable product
- the `Create Invoice` policy set to `Before Delivery`
After the quotation validation and the invoice validation,
if the user:
- cancelled the invoice,
- then validated it again,
- then hit `ignore exception` on the sale order
- then registered the payment on the invoice
The picking of the sale order was not created automatically,
and the sale order was therefore stuck.
Actually, it was just a write trigger that was missing:
The condition for the sale order workflow to go to the next state
is that the `invoiced` boolean is set to True.
It was, when the invoice of the sale order was paid
(after having registered the payment), but since
this is a computed field, not stored, no write operation
was actually performed on the sale order, and the workflow
wasn't "notified" that a change occured for the `invoiced` boolean.
A simple write on the sale order (e.g. in its notes) would
have unblock the situation, though.
This trigger ensures the worfklow to be notified when
the invoice of the sale order is paid, and therefore
when the `invoiced` boolean is set to `True`.
opw-706591
In saas-14, domain selector widgets are supposed to be instanciated
with a valid domain.
The problem is that some valid domains were wrongly evaluated. Indeed,
when receiving a domain which does not begin by an operator, the
"DomainTree" widget considered there is an implicit "&" operator that
should be used. This is not enough. Indeed, when evaluating the domain
["|", A, B, C], there is also an implicit "&" despite the fact the
domain starts with an operator ("|"). Because of that, previous
implementation interpreted this domain as ["|", A, "&", B, C] while
it should have been interpreted as ["&", "|", A, B, C].
Note: in master the parsing will be improved to handle wrong domains
and be decoupled of the DomainTree widget.
* The module was not loading the fiscal position templates before executing the template generation.
* Also, as reported in #15384, at the second installation it was crashing because of a missing xml id (which is not supported currently). This last bug was fixed by giving specific xml_ids instead of skipping the data.
This reverts commit 929d983575.
In some cases, the records have no xml_id like
in module l10n_jp, the way the account.fiscal.position.tax.template
are declared in account.fiscal.position.template.csv doesn't set
an xml_id for these records. So when using, the function create_record_with_xmlid
it raised an error if the record has no xml_id because it tried to concate
a string with a boolean with "str(company.id)+'_'+template_xmlid.name".
Fixes: #15384
opw:707704
When we add a SO line on a sale order with a product packaging, a
traceback is raised.
The problem comes from a default value and a domain set in the context
which reference a product template but since this rev: 796900feb7
the product packagings are linked to product_product and not
product_template anymore.
So we used the product_id field instead of product_tmpl_id. And remove
product_tmpl_id from the sale_order_line model which is not used anymore
This is a complement of previous commit.
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company banking
information displayed in the report footer.
opw-708581
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company contact
information (address, phone, fax...) displayed in the report footer.
This is due an API migration error (7eab8e26d3). Before the migration,
the partner was browsed in `_get_address_data` as:
`address = part_obj.read(cr, openerp.SUPERUSER_ID, ...`
After the migration, this is not browsed as superuser anymore.
Therefore, users with limited access rights won't be able to read it
anymore.
opw-708581
Only allows a manager to unlock a PO. Otherwise, when the option
'Confirmed purchase orders are not editable', any user can unlock a PO
and modify it.
opw-707035
Simon Lejeune