The _message_post_helper() method historically allowed
passing a `sha_in` signature to let an unauthenticated
user post a message on a record.
This option is unused and an alternative is preferred:
passing a `token` value that matches the value of a
given field of the record.
In light of the increasingly grim future of SHA-1
as a cryptographic hash function, we consider it
better to entirely remove this specific option.
It has been unused for a while, and a simple
alternative exists.
The `object_shasign` method itself will be dropped
in master.
A company should have at least a pricelist having the same currency, that's common sense.
This was causing problems in tests on 10.0-nightly, where the main pricelist was created
in EUR, then the localization module was setting the right currency on the company without
any reflection on the pricelist.
To avoid this problem, when we write the currency on a company, we reflect that change on
the main pricelist if it's the only company in the system. Otherwise as we can't decide
which pricelist modify, we just create a new one, which should be ok.
When get_price() is called during tests, a ValidationError was returned but not catched
correctly due to the unavailability of delivery service.
Because this method is called during the creation of new sale order, it leads to some
operational error (broken cursor).
(1) The priority widget is based on a selection field.
So, this priority widget must support string values.
Before this commit, the widget worked correctly with numeric values.
For example: '0', '1', '2', '3' was converted to 0, 1, 2, 3.
But sometimes, we have non-numerical values.
For example: 'Normal', 'Low', 'High', 'Very High'.
In this case, we can not compare the elements to each other according to their values.
If you select 'High', we don't know if the star of the value 'Low' must be filled.
To fix this, we base the comparison on the indexes of the table of possible values.
For example:
[('A', 'A'), ('B', 'B'), ('C', 'C'), ('D', 'D')]
Now, if you select D, we know that A (with index 0) is smaller than D (with index 3).
This could be a behavioral change if you had [('1', '1'), ('0', '0'), ('2', '2')]
(2) When the selection field had no value, the 'o_form_field_empty' class was added.
In this case, the stars must be displayed without being filled.
A user may want to enter a coupon on the 'Payment' page, for example after he selected his delivery method. That way, he isn't forced to come back on the 'Preview Order' page to enter the coupon and reselect its shipping and delivery addresses.
When the function map_tax is called on the fiscal position in repair
lines to compute taxes, the partner and product are not passed to the
method which leads to mistakes when the module account_taxcloud tries to
get back the taxes for the specific partner and tic_category of the
product.
To fix the issue, we pass the product and partner that we already have
to the function map_tax.
When updating several moves for the same product, each time a write was done,
the move.product_id.standard_price was not updated due to "with_context(force_company=move.company_id.id)"
before write. Making a with_context before write changes the environment of the write, this why the cache
was not updated.
opw:709329
The `rating_last_value` field was a related on the One2many
field `rating_ids`, on which the domain
`[('res_model', '=', self._name)]` is applied.
The problem is that this domain is not taken into account
when retrieving the records for which this value must be recomputed
Therefore, when computing the `rating_last_value` of a record,
if there was a record with the same `res_id` but another
`res_model`, the `rating_last_value` of this other record
is recomputed as well.
And, if you did not have the write access rights on this other
record, it raised a security exception.
There is at the moment no way in the ORM to filter the
depends on a specific subset of records for which
a computed field must be recomputed. Therefore,
we have no other choices to make the recomputation
of the records value as sudo. It will
recompute the value of other records which have nothing
to do with the one on which this value must be recomputed
(nothing to do except the id of the records which is common),
but at least it will succeed.
opw-709349
To reproduce:
1. Set a product with 'Perpetual (automated)' valuation and 'Average
Price' costing method.
2. Make a PO of 2 units, unit price 100, receive the delivery
=> Cost of product is 200 / 2 = 100
3. Make a SO of 1 unit, unit price 250. Confirm the SO, but do not
deliver the product and do not create the invoice.
4. Make a PO of 1 unit, unit price 200, receive the delivery
=> Cost of product is 400 / 3 = 133.33
5. Deliver the product sold
=> A debit of 133.33 is created on the 'Stock Output Account'
6. Make a PO of 1 unit, unit price 250, receive the delivery
=> Cost of product is 516.66 / 3 = 172.22
7. Create the invoice of the SO
=> A credit of 100 is created on the 'Stock Output Account'
There is an inconsistency between entries created at steps 5 and 7. The
reason is that the price unit on the stock move is not updated when the
delivery is completed.
opw-709726
When uninstalling the module sale_margin, the view 'sale_report' was deleted
because this view was overwritten in this module.
But the module sale still uses the 'sale_report' view so it raised an error
each time this view was required.
opw:709328
Due to these commits, it was impossible to make an uninstall_hook
just after an uninstallation.
In some case, it 's needed to make an uninstall_hook just after the uninstallation.
Look this commit for example: e03c919e9955c5d3f678c0580744d9ef8c483c74
When the internal category of a product is in costing method = "Average Price"
and Inventory Valuation = "Perpetual(automated)", a button with the label
"Compute from average price" was displayed. But when clicking on this button,
it just allows to set the standard price. So the label of this button must be
"Set standard price".
opw:709329
- Create a partner with an invoicing and a delivery address.
- Connect to the website as this partner, create an order
- In the "Shipping & Billing" page, the delivery address is selected
automatically. Change and set to "Ship to the same address", and
confirm.
The "Ship To" address is still the delivery address, while it should be
the same than the "Bill To" address.
This reintroduces the v8 behavior:
`order_info.update(partner_shipping_id=checkout.get('shipping_id') or partner_id)`
https://github.com/odoo/odoo/blob/8.0/addons/website_sale/controllers/main.py#L623
Create the following
- Create a partner of type "Company" (Address 1)
- Add an "Invoicing" address to this partner (Address 2)
- Add a "Contact" address to this partner
- Authorize this contact as a portal user
Connect as the portal user created:
- Place an order from website, add a product to cart
- In "Shipping & Billing", confirm the order. The proposed billing
address is "Address 1". Do not change the shipping address ("Ship to
the same address"), and confirm.
The "Bill To" as well as the "Ship To" address are set to "Address 1".
This is a regression from v8. In v8, "Bill To" is set to "Address 2",
while "Ship To" is set to "Address 1".
opw-707283
The variable `st_line` was used outside of its scope,
in the line
`move.line_ids.filtered(lambda x:x.statement_id == st_line.statement_id).write({'statement_id': False})`
It leaded to issues when calling the method
on multiple `account.bank.statement.line`: Only
the items associated to the last line were unlinked
opw-709196
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
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
Olivier Dony