| Age | Commit message (Collapse) | Author |
|---|
|
This commit introduces a new module system for the javascript code.
Instead of using global (namespaced) variables everywhere (like
openerp.web.whatever, ...), each file declare one (or more) module
with its dependencies. Each module will be loaded after its
dependencies, and will be given a reference to the return values.
This change is a massive departure from the way the client worked
previously. It will sadly break some/most history, but I am sure that
the future git ecosystem will allow you to easily browse the history
past this revision (one can dream).
This commit feature:
* main namespace is now odoo instead of openerp
* a way to define modules and dependencies (inspired by requirejs)
* many files have been splitted in simpler subfiles
* basic support for debugging in odoo.__DEBUG__
* no global variable (i.e. nothing in window.openerp)
* many bug fixes, many new bugs
Future vision: this modularization should simplify future code
development, simplify debugging and will allow a serious testing effort
|
|
with the website builder
|
|
|
|
This is related to rev. d17f22cde77fd6dd0fb968b1b34883c56648e93e
Compare float values using float_is_zeor only
if the key is 'value',
meaning the changed value is the actual value of the field,
not another variable of the field (widget, etc.)
For instance, changing the currency_info of a float field
using the monetary widget should not compare the old and new value using
float_is_zero (the values are not even floats).
opw-627166
|
|
ignore .po and .pot changes
|
|
This rev. is related to d17f22cde77fd6dd0fb968b1b34883c56648e93e
|
|
When setting a float field,
the web client rounds the value entered by the user
using the instance.web.round_decimals method.
Nevertheless, this is possible that this method returns unrounded float,
due to the float precision
For example, round_decimals(53.8, 2) returns 53.800000000000004
In order to compare this new float value to the old float value
and check the eventual change),
we need to check if the delta between the two is almost 0.
This is the goal of the float_is_zero method introduced during this rev.
which is comparable to the float_is_zero method
already available in the openerp server, in openerp.tools.
Float values compared using the simple === operator
instead of this float_is_zero method
will be regarded as different in some cases,
according to the float value and the precision
And the value of the field will be regarded as changed,
which can lead to unwanted triggers of onchanges.
opw-626635
|
|
Damn you commit -a
|
|
Make the field description on a forum translatable and add it in the forum view. opw 619786
|
|
jquery's `replaceWith` function behaves differently between 1.8 and 1.9.
This function is used by `renderElement` of the Odoo widget API and, when
called on a template with multiple root nodes, will fail to replace the
whole original nodeset by the new but instead will replace every node
by the new nodeset.
Sample:
1) Suppose a DOM containing
<div>1</div>
<div>2</div>
and a jquery nodeset [<div>1</div>, <div>2</div>] referring to the
previous DOM part in a var named $oldel.;
2) suppose another jquery nodeset [<div>3</div>, <div>4</div>] in $el;
$oldel.replaceWith($el) will result in
"3434" in jquery 1.9.1
"34" in jquery 1.8.3
This issue particulary concerns us when the dom of a widget is not wrapped
into single tag and when re-calling renderElement (triggering replaceElement).
The fix is to wrap the element to be replaced ($oldel in the example) behind
a div before calling replaceWith.
|
|
it was trying to call the forme 'hide' method on the searchview. To
solve the problem, I readded the method (and renamed it to do_hide for
consistency with views)
|
|
|
|
sessions being created for every call
|
|
mostly styling, and related micro-changes
|
|
|
|
Also fixed Widget#alive's behavior and tested it
|
|
|
|
bzr revid: fme@openerp.com-20140506103649-wrfa25boj2chy6gl
|
|
bzr revid: al@openerp.com-20140131005202-sjsfy3tc8ys1a325
|
|
bzr revid: fme@openerp.com-20140130151146-twct15ruxq179ryu
|
|
This way, the client can send genuine local Date objects without
caring too much, the server will get them in an expected format. This
can then be used by leaving Date objects in domains, and have these
date objects end up correctly in the server without creators of
domains having to manually serialize them to UTC from a local datetime
somehow.
bzr revid: xmo@openerp.com-20140122135426-zm80cj5wm9iebs76
|
|
bzr revid: tde@openerp.com-20140103151458-8hl5qlmswpxdvd7v
|
|
dle@openerp.com-20131218112416-2vtaq442qo8opq4u
bzr revid: mat@openerp.com-20131218165033-4djghawrzllkeckg
|
|
openerpframework.js can be used as standalone library (im_livechat uses
it this way) and do not depend on underscore.string.js
bzr revid: chs@openerp.com-20131203132937-ss7hx1gligzai5ch
|
|
bzr revid: chm@openerp.com-20131202151847-4sf0ww58meql0e4z
|
|
chs@openerp.com-20131122172422-tsd8wzqkbqknrw1w
bzr revid: chs@openerp.com-20131125160506-30uia4pdwzpp54gj
|
|
bzr revid: chs@openerp.com-20131113184000-3k3dnwl5ftllq2rv
|
|
bzr revid: xmo@openerp.com-20131113151911-l4f7vlzkcht38nuc
|
|
chs@openerp.com-20131031111945-u3wi11e4rykpslme
bzr revid: chs@openerp.com-20131030183314-d75tbpxjjk3u79er
bzr revid: chs@openerp.com-20131031144026-09f3eqfwfj2bcefs
|
|
When creating a new Date object at a specific date, this date is treated as a UTC datetime
then normalized to the browser timezone. This can lead to a change of Year/Month/Day depending
of the chosen date. Using a date of a leap year date for date parsing and forcing UTC date for
datetime parsing correct the month-switch errors in all timezones
bzr revid: chs@openerp.com-20131031133920-yl5z4oz939smwvz8
|
|
avoid reading wrong cookie by matching the whole cookie name
bzr revid: chs@openerp.com-20131107143212-50hrpvkaw3gxxlop
|
|
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
|
|
bzr revid: nicolas.vanhoren@openerp.com-20131011133054-0dx3wxqcqbdocnlf
|
|
bzr revid: nicolas.vanhoren@openerp.com-20131011095424-midppkv5czebt1f2
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130819092408-rdi91pokwuuy3f5e
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130808134520-v0n2b29vuffstyu0
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130806132807-rbiafmcqvbh1o79y
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130806131746-l43mz6aos7eupehm
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130806130734-lov3aq0m4b1r4sto
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130806122623-pq6bpkjk65jx0fnp
|
|
the openerp.web namespace.
bzr revid: nicolas.vanhoren@openerp.com-20130806085812-ek8v8k0x4m7ocu4f
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805151544-pdaebd2o8bh70z7z
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805151012-wnc7wkyiz0eay5oh
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805145514-uuywlhleyfz2xoj4
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805134059-3ayw6b0tqqberkaw
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805133309-jds80qa5j5lgwslq
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805123916-s62upxq3jwqjygt0
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805111250-ws23n3b6os54qsp3
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130805101849-rqqx4jcmbymv5hfl
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130802152432-stvg9eed7f6juvq9
|
