This fix is related to revision 3985 revid:dle@openerp.com-20140326142040-pls0dk2kd03z55ro, which did not worked for buffered dataset (virtual one2many line in view form
search_read is used instead of read to not return records for which we lose the access rights
bzr revid: dle@openerp.com-20140327112456-iyceuf9dnn07hwke
BufferedDataSet.read_ids assumes the input and output orders are the same, and
returns wonky results when not the case, which in turns fucks up its cache as
it associates ids and records incorrectly.
bzr revid: xmo@openerp.com-20140225162813-8ofxpiy1012eehgk
* Alter datetime.now(), generate a local datetime (add utcnow() which generates a UTC datetime)
* Implement datetime.replace() to manipulate local datetimes
* Implement date.today(), generates a local date
* Implement datetime.toJSON(), returns a javascript Date (assumes datetime attributes are local)
* Add conversion hook in JSON and JSONP handlers, automatically converts a Date object to a UTC datetime formatted according to server formats
Should allow the generation of correctly working (from the end-user's POV) [Today] filters, amongst other things.
Eg: a local expression in a domain for 'Today 00:00:00' would now be expressed as 'datetime.datetime.now().replace(hour=0, minute=0, second=0)' (no .strftime) and will be converted to UTC when sent to the server
bzr revid: mat@openerp.com-20140128133706-4yp610pp5w06tcia
* change datetime.now() to generate user-local naive datetimes
* add datetime.utcnow() behaving as the old now()
* add date.today() generating a user-local date (for the current day)
* add datetime.replace() to replace any specific attribute of the
datetime object (except tzinfo, for now)
* datetime.toJSON() now returns the equivalent javascript Date object
(warning: uses the datetime attributes directly, since datetimes are
naive if they were created with utcnow() the Date result is going to
be complete nonsense). With the previous commit datetime.now()
generates a user-local now() which is converted to the correct UTC
datetime when sent to the server.
This means it becomes possible to generate datetime bounds for the
user's local today with either
datetime.datetime.now().replace(hour=0, minute=0, second=0)
or
datetime.datetime.combine(
datetime.date.today(),
datetime.time())
and once send over JSON-RPC the server will get the local datetime
in UTC to the server's format.
nb: user-local means "in the timezone of the user's browser" in this
context.
bzr revid: xmo@openerp.com-20140122151911-akn1nr6e739eg92s
As `new Date()` return the current date, when we are the 31,
setting the month to a month with less than 31 days will change
the date to next day (1st of next month). This result to a date(time)
object one month ahead of the wanted date(time).
bzr revid: chs@openerp.com-20131031103333-vt68132ptj9sbr04
There seems to be a problem with QUnit's serialization routines when
applied to complex widgets (the view here) while running inside
PhantomJS. It does not seem to be cycles in datastructures (that is
handled) but looks related to complex objects linked from multiple
"children" (skipping any object already serialized makes the issue
disappear).
The bug leads to unbounded memory growth, and on runbot to the process
being summarily terminated (likely by the OOM killer) not even
resulting in an OOM error (which is displayed locally). The issue can
not be observed within browsers. This may be a difference in GC
strategy.
The serialization is applied by the driver on high-level comparison
methods (e.g. strictEqual) so the caller can display the structures if
desired.
Replace the strictEqual(a, b) call by ok(a === b) to avoid any risk of
such serialization.
bzr revid: xmo@openerp.com-20130801091326-u2q9e163zls4k8ad
JS objects are converted to py.object when passed in through the
evaluation context. py.object are not serializable by default (because
that doesn't really make sense), which breaks when the input is
intended as a dict and returned (e.g. o2m values, which are triples of
(int, int?, dict?)).
Intuitively, JS objects passed as part of the context should be mostly
JSON-ish and thus dicts, but that turns out not work work as some
addons use attribute accesses within contexts (e.g. parent.access in
account/account_invoice_view.xml)
=> Temporarily solve by converting raw js objects to an "attributed
dict" which acts as both a dict and an object and can be converted to
JSON.
Ideally, py.js should provide for a pluggable conversion, or should
use an attributed mapping internally. See issues 21 and 23.
lp bug: https://launchpad.net/bugs/1182101 fixed
bzr revid: xmo@openerp.com-20130624055929-3rtkgqrp4o87pvau
integer/float fields were not offering auto-completion in search views,
making them unsearchable except via advanced search.
This patch adds the missing complete() function and removes the incorrect
value_from() function that did not conform to the 7.0 search view API.
It seemed to be a leftover of the 6.1 search field implementation
of get_value(), wrongly renamed for 7.0.
Also includes corresponding tests.
bzr revid: odo@openerp.com-20130418112001-388op1t8ugr0rhfn
Denis Ledoux
Olivier Dony
Xavier Morel
Antony Lesuisse
Martin Trigaux
Gery Debongnie
Christophe Simonis
niv-openerp