In python3, items() and keys() returns iterators.
Modifying a dictionnary while iterating on it may trigger an error:
dictionary changed size during iteration
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Up to this revision, clicking on 'edit' in a record with an existing pad
and discarding the changes straight away caused the pad content not to
be displayed.
The root cause of this issue is twofold:
- a hack tricks the model into thinking the pad URL has changed by
replacing it with an object yielding the URL when JSONified;
- the pad never affects the 'dirtiness' of a record and BasicModel only
actually discards changes when the record is dirty.
When a user clicks on discard, the model does not actually discard the
changes, thereby leaving the web client into thinking the pad URL is the
object mentioned above.
We fix this issue by requiring that the model always discard changes
when clicking 'Discard', regardless of whether the record is dirty.
In fact, the lines we changed were no longer correct since the
introduction of 'doNotSetDirty' (see
https://github.com/odoo/odoo/commit/72ed3a1), as a record could be
changed without being dirty. This commit thus also ensures that such
records are also properly discarded.
Dominican team is focused on Transifex traductions using es.po,
as es_DO.po has a lot of issues in the website and reviewed strings
with wrong wording and mixing english and spanish. From now on
Dominican Republic will inherit es.po and just make specific changes
on github just in the needed words or setences that change base on
region.
Closes#18834
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
Backport of 0de067cae9
(and 9b8bc5e5a1)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
The goal of the commit https://github.com/odoo/odoo/commit/c5bd509 is to update the etherpad content if the description field is updated.
However, if the pad is not initialized yet, we shouldn't try to do this obviously.
Before this commit, the pad widget did not force the view to save the
current value, since it did not change (pad values are just the url for
the pad). However, this is a problem for the server, since it uses the
fact that the web client forces a save to update the description field
in the model (get the data from the pad server and add it to the
database).
This was not a big deal when looking at the pad (the pad widget fetches
its data each time), but it is a problem that the database is not
synchronized with the current data.
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
If the pad content field is modified in Odoo, the content of the pad should be modified too.
Example: When merging tasks, the tasks descriptions are concatenated into the target record. But the taregt pad is not modified if it already exists.
Odoo Translation Bot