The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
This change will prevent the document from going from Done to Draft
In some cases a user may make that error functionally. It is only to have an additional validation
In the past, we didn't need this validations because the workflow didn't allow the use of a transition that is not defined on the correct state but since that we don't have workflow so we need manage this inconsistent action from original method in order to avoid a wrong transition.
Some user might be logged but not have the right to access issue or task.
Plus it does not make any sense to redirect to backend after rating a task or an issue.
OPW: 748579
It calls `onchange_state()` on `res.partner` which was removed on
(24aba60).
It was added to `res.users` long ago (009ea40) to support a `state_id`
field on the view `res.users.simplified.form` that is no longer there
since v8.0.
The method is then never called and was crashing if called.
Closes#17772
If two MOs are using the same PO, when we cancel the first MO, the
check availability of second MO is not working.
The incoming shipment of the Purchase Order has the first MO's move_id
as the destination move. When we cancel the first MO, the incoming
shipment of Purchase Order still holds the first MO's move. Because of
that reason, the check availability is not working for the second MO.
While setting the destination move for the stock moves of the incoming
shipment, it should ignore the cancelled procurements.
Closes#17701
opw-748074
Courtesy of @suganthikarunanithi
If a user tries to reconcile already reconciled lines, the calling
method might have already filtered out these lines, and the method is
called with an empty self.
opw-748223
In case you have multiple warehouses and/or multiple manufacturing
locations (procurement routes), the same sequence is taken for the
created manufacturing order no matter where it is finally produced.
Closes#17681
opw-748344
Closes#16973
Steps to reproduce:
1) Go to Settings -> Technical -> User Interface -> Views
2) Create a new view and give only name, leave fields View Type and arch_base empty.
3) Exception occures
Current behaviour:
- The user gets an exception with a full stacktrace.
Expected behaviour:
- The user should get a warning
After rev d938ba87ae, taxes that are
included in the price are subtracted in case the tax is not applied in
an order (e.g. when the fiscal position remove the tax).
Some of the test orders did not apply any tax, and because the products
used in the test had some tax included, the above revision made the
tests fail (by subtracting the tax amount from the price).
Fixed by making the test orders more consistent wrt to taxes, applying
the taxes as would happen in the UI, then correcting the payment amounts
to include the extra tax amounts.
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
Steps to reproduce the bug:
-Change the default lang on the website to be different than en_US
-Edit the name of a product in the website
Bug:
The name of the product is changed in en_US and not in the language
set on the website. The lang is in fact removed from the context in
function saveElement(in addons/web_editor/static/rte.js).
opw:747084
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
If the user change the access right to filter some stock location or multi
company, the user can have an access error to read stock pack operation.
opw-747526
Before this the -webkit-text-security CSS property was used. This, as
the name implies, only works in webkit based browsers. Instead we can
just render the PIN code as •'s since the value of the inputBuffer is
used (not the rendered text) when checking the PIN.
Fixes#16458
In version 8.0, there was a stored field `minimum_planned_date`.
In version 9.0, this field was renamed `date_planned` and loose it
store attribute.
In version 10.0. the field is stored again.
Keeping this `oldname` attribute will lead to reuse old data from
version 8.0 when migrating the database to version 10.0.
Closes#17631
opw-744097
Let's consider 4 products P0, P1, P2 and P3 where:
- P0 depends on P1, P2 and P3
- P1 depends on P2 and P3
- P2 depends on P3
NB: "x depends on y" means that there is a phantom BOM for x where
y is in a line.
With this example, before the fix, when creating a MO for P0,
the function "explode" raised a user error saying that there
was a recursion error.
Even if in this case there was no recursion.
Now to check if there is a recursion, a graph of the dependencies of
the bom is created while exploding the boms and a function "isCyclic"
is applied on the graph to verify that there is no cycle which means
no recursion in the dependencies.
The algorithm was taken from this site: http://www.geeksforgeeks.org/detect-cycle-in-a-graph/
opw:745453
When several user run a production on a workorder, things go awry.
For example the end of the "productive" production is computed based on
ProductiveStartTime + DurationExpected - Duration
so if the duration was bigger than the time expected, we easily get a
productive end before the start, and start of the "reduced speed" before
the production actually happened.
eg:
productive time is 30 minutes
user A: start production at 10:00
user B: start production at 10:10
production is set to done at 10:50
=> result before the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has been productive from 10:10 to 10:00
user B has not been productive from 10:00 to 10:50
this is totally erroneous.
=> result after the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has not been productive from 10:10 to 10:50
this is a measure of right, we could argue about wether one or the other
should be productive or not but this is anyway an edge case.
In master we are considering only allowing one user to run a production
at a time but we prefer not to change such a behavior in stable version.
opw-709223
closes#17528
Martin Trigaux