When clicking on the smart button "Claims" of a contact, it shows
a tree view with all the claims of this contact and his children(because
the domain on the filter is [('partner_id','child_of',self)]).
So the function _claim_count has to return the sum of the # claims
of a contact and the # claims of the children of this contact.
opw:708698
The revision
dd657c42f7
intended to give the possibility to add an existing
record to a many2many list even without the `create` access
on the model of this record.
This is accepted by the ORM, as there is no need of the create
right on the model, only the write on the source model on which
the many2many field is.
The revision has as unexpected side effect to remove the possibility
to manually set `create="0"` on the tree of a many2many field,
to hide the "add an item" of the list view.
As this last feature is more important, we therefore revert this.
We will provide another solution for the above issue.
We think about forcing what the view definition says, so if you
set create="1" on the view, it will display the "add an item" link
in any case, even if you do not have the access right to do it.
This would allow to display the link for the above case, and in case
you actually do not have the access right, and this is an error
in the view definition, you will have an access error raised anyway.
opw-708310
The previous code (`parent.field_widget.string`) was returning the untranslated
action name (and why use parent anyway?)
Use the action name instead.
Closes#15207
opw-705938
The field "costing method" on the product.category only appears when
the inventory valuation is set to "perpetual (automated)" which is
wrong. The user must be able to choose the costing method no matter
which inventory valuation method is chosen.
The problem is due to this commit b6a2c0a4ce
that changes the xml view and make the field invisible if the inventory
valuation is set to "Periodic (manual)".
This commit revert the change on the xml view and thus add again
the group attribute that should not have been removed.
In `_prepare_procurement_group`, self.name is accessed.
The method should then use api.multi instead of api.model
Can not backbport as may be problematic if override in old API
Closes#15510
For a pricelist based on another pricelist,
the price of the product is the price in this other
pricelist.
To get the price of a product in a specific pricelist,
the field `price` must be used, along with the right `pricelist`
passed in the context when browsing the product.
Without this, the sale price is considered the sale price
indicated on the form, in the product company currency,
while the pricelist on which is based the currenct pricelist
could give a specific other price, in another specific currency.
e.g.:
Watch, Sale price 690CHF
Public USD Pricelist, setting the sale price of the watch to 790 USD
Reseller USD Pricelist, discounting 60% based on the public pricelist price, discount shown.
Before this revision, the sale price of the watch was marked
690 USD, with a sown discount of 54,xx %
With this revision, the sale price of the watch is marked at
790USD, with a shown discount of 60%, as expected.
opw-708301
The name_search was not working properly if limit=None is specified (e.g.
searching for the search bar on a many2one field to product.template).
As `any int > None` is true, the condition is always validated as soon as the
search returns at least one result.
The product.product search has no limit parameter and use the default 100.
If the 100 first products have only a few templates (a lot of variants), the
result will be incomplete as stopping after the first iteration.
Closes#15477
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.
Goffin Simon