The current calculation of work days is inconsistent with the leaves of
the employee in several cases.
The core of the problem is the logic of the algorithm: for a given day,
if we can find one hr_holiday within this day, we consider it as a
leave. One can easily spot several issues with the existing logic:
- if an employee takes less than a day-off (e.g. a half day), the
complete day is considered as a leave.
- the timezone (TZ) is not taken into account when searching for a
leave, while it is when computing the number of working hours. A leave
from 3:00 AM to 3:00 PM in the Los Angeles timezone would then be
considered as two days-off since it spread on two days in UTC.
The logic is therefore completely modified. For each day of the period:
- compute the work intervals (TZ taken into account, converted in UTC)
- search for a hr.holiday which completely includes the work interval
- if a holiday is found, the work interval is considered as a leave.
Otherwise, it is considered as a normal work period.
This is a first step in improving the logic. The first faulty use case
is partially solved, since we cover now complete work intervals.
However, a leave covering only partially a work interval will not be
taken into account.
The second faulty use case is solved.
opw-707897
The below revision:
9bea8a8bd3
Change the behavior on how are computed the children hours
according to their stage fold state, while it was not intended
to. The subject of the above revision was an issue
in the recomputation dependence for the field
`children_hours`, but not how the field was computed.
It's important to count the effective hours when the
sub task is in a final stage (e.g. done) rather
than the planned hours in this case.
opw-709008
The computation of the `children_hours` wasn't
reset at each compute, and they ended up
to be added at each recomputation involving
the method `_hours_get`
This is a regression during migration to the new api
in revision
e6ac7a7d25
opw-709008
The task progress value depends on the stage of the task,
if it's a folded stage or not.
If the task was being changed of stage, from
a non-folded stage to a folded stage,
the recomputation of the progress was not done,
while it was needed as a task in a final
stage is considered to be done.
This is a regression during migration to the new api in
e6ac7a7d25
Links containing HTML escaped characters,
such as the ampersand
`&` escaped `&`
were not shortened correctly:
Their redirecting URL contained the escaped value
(e.g. `&`) instead of the actual character,
leading to the wrong redirected URL.
e.g. creating a mass-mailing with a link
contains as query string
?test1=1&test2=2 were shortened
with as redirect link
?test1=1&test2=2
opw-708272
In a lead:
- Fill in contact information (phone, address, email...)
- Create a new contact
All information is copied to the new contact, except the email.
opw-706711
When there is no move line linked to the picking, the customer address must
be the address of the partner linked to the stock.pick
Fixes#15092
opw:707890
Currently if an user mentions someone in an internal note he is not
notified of any reply as replies create internal notes. This commit
ensure the author of the first note is notified of the reply even
if it is still an internal note.
Tests have been updated accordingly.
Replying to internal notes should create internal notes and should
not notify anyone. Future commit will change that behavior. This
commit ensure the current behavior is working as intended.
* Limit company image to match buttons size and avoid badly
sized image
* Add a margin below internal note notice because it currently
overlaps with actual email content
* Avoid having signature direclty included in message by
enclosing body in a div
Commit 3c9e6c89e7 made big changes to the
link editor dialog... but also broke many features with it.
Commit 9a1ea6dc08 already fixed some of
them but this commit fixes a bigger one. Indeed, the menu edition
feature was totally broken since the changes. Also, the DOM was messy
which broke form navigation, etc.
This commit also simplifies the LESS which was uselessly big.
Without passing `active_test=False` in the context,
a one2many fields exludes the record with
`active` set to False.
For an archived product template, this means
`product_variant_ids` returned an empty array
opw-708828
If amount = 1 and the category amount = -1, the sum is 0 and the returned
value was amount instead of zero (`0 or amount`)
Avoid this evalution error by splitting on multiple lines
Closes#15470
When creating an opportunity from the kanban view with the crm.lead.form.simple,
setting the partner_id didn't set the fields email and phone by the onchange.
opw:708514
When installing costa rican localization the partners titles has
a wrong reference to base module that cause a warning messge in
server log. In total the localization had 8 partners titles that
not exists in base which was removed the reference and another 2
that exists in base but not had any difference.
Courtesy of Vauxoo.
Closes#15495
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.
Nicolas Martinelli