The list of records can be part of a large browse list which may be also read
when accessing attribute of the record. To prevent that we must use a new
browsing list.
issue10632
review334631003
(grafted from b799fb16468dec19830732f762088051140a1b53)
--HG--
branch : 6.0
It is not really useful because the id of the future record can not be guessed
for sure by the client.
Also when write is called with such fake _timestamp as singleton create the
record before actually write, the timestamp check always fails (if the id was
correctly guessed).
issue10282
In case a Dict field is sent during an on_change, modification of its value
won't be detected because a shallow copy will keep its reference in the
pseudo-record
issue10105
review347541002
If there are multiple translations for the same record, the join will generate
result with multiple times the same id on ModelSQL.search.
As DISTINCT ON is not always supported, we must also ensure that duplicated
translations are all updated.
issue10061
review351261002
In order to relax internal control of record rules, they must be enforced on
the button entry point.
This is done by just reading the id of the records already stored.
issue7638
review349381002
It has a cost to instantiate such fields and there is not guarantee that they
will be used. But as their values are stored in the cache, if they are needed
they can be instantiated using only the cache values.
Also there is no real benefit in instantiate two fields together.
issue10026
review341251002
The same record can be passed multiple times in the list. So we must update all
of the new records with the translated value of the fields.
issue9866
review353091002
There is no need to enforce access right on instances because only internal
code can use them and the design is to only check on the external calls.
issue7765
review322581002
We must convert in ModelSQL.read the rule domains like the ModelSQL.write and
ModelSQL.delete convert their rule without the active test to have the same
result.
issue9819
review300951006
The value of a field, added to the view because it is a depends, may not be
correctly computed if it is missing its own depends.
issue9828
review292751003
They can not be displayed by all clients (nor OS).
But also they can be trimmed automatically by web input which breaks comparison
against changes.
issue9248
review312681002
Each value of the 'in' operators must be processed as a '=' clause.
The None values must be supported just in case it set in the 'in' values
because the mixin does not allow empty name.
issue9354
review304601002
The client may not send the values for the xxx2Many if they have not been
loaded. So in order to provide proper changes to apply once the values are
loaded we must base those changes on the current data stored.
issue9719
review308391002
This avoid to fill an instance with None value which will prevent it to be
saved with the default value for fields not explicitly assigned.
issue9726
review314481004
Cédric Krier