Before this fix, a traceback occured when we clicked on the translate icon
in a form dialog.
The `translate` event wasn't stopped and was thus handled by the dialog's form
controller and by the main controller.
Before this fix, multiple records were created if you clicked
on the quick create of a many2one in a modal.
The 'mutexify' event wasn't stopped and was thus handled by
the dialog's form controller and by the main form controller.
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
The module `crm.voip` alters the focusable behaviour of the phone
widget by overriding the `canCall` method.
We thus disable this test if the module is installed.
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
Rev. https://github.com/odoo/odoo/commit/c5f8f35747b4ca9633c664d6be74614c5ce22fcd
introduced a regression: the input of widgets 'email' and 'url' was not correctly
focused anymore with tab navigation.
The method `getFocusableElement` on their common parent (`InputField`) has not been
correctly overriden because `_super``was not called in edit mode.
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
Now, an abandonned cart is:
- a draft quotation
- in a sales channel with type = website
- with a customer set (not public user)
- created more than one hour ago
- removed from_website filter in search view of website sale, added domain in view for display website side sale
- use proper filter for display 'Orders' and 'Orders to Invoice' in dashboard
this commit closes#17383 task-745391
Before this fix, it was possible to set the widget 'pad'
on char fields but it only worked if the current model
inherited from 'pad.common'.
In the other cases, it crashed on closing Studio.
As there is two models only (project.task and
note.note), we decided to remove the possibility to set
this widget in Studio.
opw-745997
During the formating method, the country code
was compared to the country phone code. Indeed,
phonenumbers python lib return a `PhoneNumber`
object having a `country_code` attribute
refering to the country_phone_code, and not
the country_code (like odoo means).
Consequence: changing the country on a lead
did not make the phone validation work.
Thus, it was required to give both code (country
and country phone codes) to the phonenumbers API,
in order to make a correct verification.
When refusing leave, we can not remove linked timesheet,
since they are attached to the leave.
We need to first detach it, then remove the timesheet
entries.
Also, add a test about the removal of linked timesheets.
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
The tab navigation was only working in edit mode. Entering a readonly form
view with input fields was causing a traceback.
As the default browser behaviour has been overriden with custom navigation,
we need to specify which widget can be focused (e.g.: url, many2one, etc.).
In an empty kanban view, when moving a freshly created record from
the second column to the first one, then moving it back again in to
the first one, the record was mysteriously duplicated.
When moving the record, it should be removed from the old column.
In this case, the second column was not found (and thus the record
not removed) because the iteration was on `parent.count` (which is
the count of records in this datapoint (1 in our case)) and not
parent.data.length (the number of columns).
The mentioned commit exposed a `Dialog` instance thanks to a return and
an event triggering. The forward-port failed in saas-14 as the code
landed in the wrong function.
As the event trigger seems to be useless code without any context and
that this code has been hugely refactored in recent versions, this
commit simply removes it.
Feel free to expose variables again in version 11.0.
opw-748027
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
When the user processes a picking with a large amount of pack operations
but validates a few lines (the remaining goes to a backorder), the
operation can fail due to timeout.
Closes#17670
Add the TZ to the datetime tracking. At the moment, the TZ is fixed: it
is UTC. However, this avoids any ambiguity when the tracking message is
sent by mail, since in this case, the datetime is not converted
automatically to the TZ of the user.
Adding a simple 'Z' makes the datetime compliant with ISO 8601, so it is
supported by the web client as well.
opw-747367
Set up:
- Use the usual working schedule from 8:00 to 12:00 and 13:00 to 17:00.
- Set the OS and user TZ to Australia/Sidney TZ (restart your browser)
- Create a BOM with 3 work orders, taking 1, 2 and 3 minutes (you can
use the 'Assemble Furniture' routing)
- Create a MO using the previously created BOM, e.g. for '[FURN001]
Computer Desk'
Case 1: Plan to start the next day at 08:00, e.g. 2017-06-08
The result is amazing. The system probably hit a flaw in the space-time
continuum, which can only be explained with M-theory:
- WO1 is planned from 2017-06-08 08:00:00 to 2017-06-07 08:01:00
- WO2 is planned from 2017-06-07 08:01:00 to 2017-06-06 08:02:00
- WO3 is planned from 2017-06-06 08:02:00 to 2017-06-05 08:03:00
Case 2: Plan to start the next day at 11:00, e.g. 2017-06-08
Once again, the result is literally a piece of art:
- WO1 is planned from 2017-06-08 11:00:00 to 2017-06-08 08:01:00
- WO2 is planned from 2017-06-08 08:01:00 to 2017-06-07 08:02:00
- WO3 is planned from 2017-06-07 08:02:00 to 2017-06-06 08:03:00
To solve the problem, a first commit is made in MRP to force the end
date to be larger than the start date. That hides the issue, but it
doesn't solve it.
To prevent the system to hit the 88 mph and go back in time, we force a
'hard limit' to prevent any selection of intervals starting before the
requested start time.
opw-745905
Christophe Simonis