We clear the input field when clicking 'Create and Edit' to ensure that
the field is empty if the user chooses to cancel the record creation. If
a record is indeed created, then the field value will still be updated.
Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.
Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.
In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).
ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).
OPW-771886
when having a tax with multiple children (grouped tax) if we use it in the reconciliation
widget while creating a new line, not all taxes children were taken into account.
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
The one2many default get code used to meddle with basic_model's res_ids
manually, which ended up desynchronizing the data and res_ids fields
of the list representation of the one2many values.
This commit solves the issue by using the proper mechanisms of the
basic_model, that is creating a proper datapoint for those ids.
Steps to reproduce the original issue:
- Install sale_mamangement, mrp and purchase
- Create a product
- In the Inventory tab, in Routes, uncheck Buy
- Check and then uncheck back any other route than Buy
- Get a traceback because we are looking for a record with a given
res_id in the list data but since they are desynchronized, data
is empty at that point even though res_ids is not.
The google 'video.google.com/get_player' URL seems to be deprecated so
the URL used by website_slides had to be updated.
Also when switching a slide URL from a drive URL to a youtube URL, odoo
still kept thinking it was a drive URL.
opw-773984
Verifies that admin operations on modules/apps are indeed performed by
an administrator, regardless of ACLs on `ir.module`.
Also logs these important operations, whether completed or blocked.
Before this the mrp.document id was used to construct the /web/image/
link which lead to the wrong attachment being previewed and
downloaded. Introduced by the refactoring that happened in
d193350c6f.
If the Odoo server runs with its sources read-only
for itself, this is not possible for the server
to touch the files contained in the assets.
In such a case, instead of touching the file,
we alter the attachment checksum, to simulate
a change within the modified date.
However, in such a case, we can only test that the
bundle is well generated again.
We can no longer check the change of version and modified date,
since the modified date of the files have not changed,
and therefore the checksum (which is based on the files
modified date, among others) neither.
Since the revision
5e3de76f36
The `::text` is included within the `unaccent` call
The expession tests have never been changed according
to this change of behavior in the building of the unaccented
queries. This has never been detected by runbot because
you need to start the Odoo server with the option
`--unaccent`
and to create the database with the unaccent extension
`CREATE EXTENSION unaccent`
to be able to fail the former tests,
and this is not the case on runbot.
On chrome only, the translate icon was over the <input/> element but
below the <input/> text... this commit fixes this by forcing
relative positioning on the icon so that it is always rendered after
the <input/> (which seems to solve the chrome bug).
The o_row class mechanism is supposed to be used to put another
element next to a field, like a button for example. However,
in the case of phone and email field, the o_text_overflow hack
gets in the way.
The problem that o_text_overflow is trying to solve is when you
have a long email, the table used to display the form view fields
tends to use very long cells (td) so it can display the whole email
address. This behavior completely breaks the form view, even though
the email address is clearly set to wrap in css. The o_text_overflow
class is a hack that forces the table to think that the email is
small, then defaulting to the width 50% css rules. If the email is
too long, it is correctly wrapped inside the cell, without breaking
the form view layout.
However, when we need to add a button next to those fields, this
hack gets in the way of the o_row class css rules, completely
wrecking it. We looked for a fix with qsm-odoo for hours but were
unable to find one that did not require a complete rewrite of the
form view css rules. In the end, we decided to remove the hack from
the phone field and keep it on the email field, as we think it is
less common to have a very long phone number than to have a very
long email.
There is a double-check (on client and on server) to prevent the user to
upload a >25 MB document. The client checks the actual file size while
the server guesses it from the total received payload. This server guess
is wrong as the extra payload is quite huge (5-10MB). Now the server
checks the real file size as it should have from the beginning.
In calendar views, the breadcrumbs should display the period
displayed in the view (e.g. in month mode, something like 'April
2017'). Moreover, the 'Day', 'Week' and 'Month' buttons should be
highlighted when the corresponding mode is used.
This rev. ensures that this is the case.
Before this commit, if a reminder was created and the dates being
formatted contained unicode characters the whole thing would break
because python + unicode is hard.
Example: Japanese with Asia/Tokyo timezone and creating reminders
of 1 day, see support ticket 771674
Christophe Simonis