bzr revid: odo@openerp.com-20120222114031-ud189sie1j3vn9g0

lp bug: https://launchpad.net/bugs/937637 fixed

bzr revid: fme@openerp.com-20120222113718-ix9kb61ij8jg4tub

bzr revid: al@openerp.com-20120222113007-tdi482n17x1j74l4

bzr revid: odo@openerp.com-20120222112555-5j7cqaimndmc2lew

bzr revid: stw@openerp.com-20120222095342-nifzjg0ilgd3ln0p

The fields.binary type allows storing arbitrary
byte arrays, but it has been used historically
to store base64-encoded versions of the binaries.
This was partially related to the way these binary
values are serialized when transferred using the
standard XML-RPC protocol.
With the introduction of JSON-based RPC calls
alongside the 6.1 web client, these base64-encoded
binaries may now be deserialized as unicode ASCII
strings instead of 8-bit strings. That seems like
an acceptable behavior and we can simply coerce
these unicode strings to bytes strings as we know
they will be pure ASCII. Any non-ASCII unicode
value for binary field makes no sense and should
be passed as a byte string directly.

Thanks to Rui Barreiros for providing the final
hint in bug 919982 comments that lead to the
identification of this bug.

lp bug: https://launchpad.net/bugs/899794 fixed

bzr revid: odo@openerp.com-20120222093937-quifmtsfc9gaa9ar

bzr revid: xmo@openerp.com-20120222085727-qdwfgx92q3yv2gsj

bzr revid: launchpad_translations_on_behalf_of_openerp-20120222065619-wdj17h21k8iuy3w6
bzr revid: launchpad_translations_on_behalf_of_openerp-20120222065704-3l8az0alwzd2mrmk
bzr revid: launchpad_translations_on_behalf_of_openerp-20120222065707-hp0u1vljdfgyjqxf

bzr revid: al@openerp.com-20120221185739-7utcld4kcnf39fg5

bzr revid: chs@openerp.com-20120221185247-ywuthx4v7oz0baty

bzr revid: xmo@openerp.com-20120221140517-fs0axg9w8irapw06

bzr revid: odo@openerp.com-20120221134930-ek2c6x3kjp6e27lo

bzr revid: jcv@openerp.com-20120221090112-74dihhclu1v36gts

bzr revid: launchpad_translations_on_behalf_of_openerp-20120218071328-fl3yjw2gawigfooh
bzr revid: launchpad_translations_on_behalf_of_openerp-20120219063344-7w5y8nkweukg0f88
bzr revid: launchpad_translations_on_behalf_of_openerp-20120220061321-0z254064e8vsx286
bzr revid: launchpad_translations_on_behalf_of_openerp-20120221063558-wc526qfv4ko5s6q0
bzr revid: launchpad_translations_on_behalf_of_openerp-20120221063603-medp0cjt2z5vy70x

lp bug: https://launchpad.net/bugs/936864 fixed

bzr revid: fme@openerp.com-20120220122208-k5pvpwodik78hnrq

[FIX] avoid adding session_id and token fields in form if they are already there, reuse existing fields instead

lp bug: https://launchpad.net/bugs/936704 fixed

bzr revid: xmo@openerp.com-20120220115704-zxo024voy3dxa7qe

This is essential to have the proper behavior for
timestamps: on the database side we exclusively 
store UTC data (no DST issues, etc.) as naive
timestamps (to prevent Postgres from messing with them).
Inside OpenERP server/addons we work again with
pure UTC data (much simpler), and only render
them according to the user's timezone when they
are displayed in the user interface or rendered
in a PDF report.

lp bug: https://launchpad.net/bugs/918257 fixed

bzr revid: odo@openerp.com-20120220105943-v3m0i50phrurt8x6

Setting 'debiti per ritenute da versare' as payable in order to handle it along with the due payments.

See http://wiki.openerp-italia.org/doku.php/area_utente/requisiti/ritenuta_d_acconto#openerp

bzr revid: lorenzo.battistini@agilebg.com-20120218133908-gh12l4d4vbw95fmd

bzr revid: launchpad_translations_on_behalf_of_openerp-20120218071814-qv5c1xw4260ns8r8

bzr revid: launchpad_translations_on_behalf_of_openerp-20120218060208-gvsm4rrkca7yv031

not actually sure if ActionManager#do_action is supposed to get a literal or a nonliteral context at this point... but ViewManager(Action) does not seem to like nonlit contexts at all so...

lp bug: https://launchpad.net/bugs/933360 fixed

bzr revid: xmo@openerp.com-20120217093541-pudzg8x4u1dhbkjf

lp bug: https://launchpad.net/bugs/928280 fixed

bzr revid: xmo@openerp.com-20120217091554-x1d0qvcvmj8z2oju

bzr revid: al@openerp.com-20120216185110-gkoqaj3ncdy52hd3

bzr revid: al@openerp.com-20120216184505-i1otb8cqauji2vun

lp bug: https://launchpad.net/bugs/933411 fixed

bzr revid: qdp-launchpad@openerp.com-20120216180111-1sfod39gvj1387eq

bzr revid: stw@openerp.com-20120216172941-21hrsi0lom3cyk0m

lp bug: https://launchpad.net/bugs/916670 fixed

bzr revid: al@openerp.com-20120216172136-rh7yk89dgztj0cdg

bzr revid: qdp-launchpad@openerp.com-20120216165253-01d70hrlf8pmnn7x

previous change would exclude all fields with @readonly, but @state can remove @readonly from fields and means fields are importable again (pretty much). Need to add that, otherwise it's almost impossible to import stuff

bzr revid: xmo@openerp.com-20120216163155-wh8uory00i2qifxy

bzr revid: qdp-launchpad@openerp.com-20120216162909-00vi550vyrukx06b

bzr revid: odo@openerp.com-20120216161805-wmqgmzt1jgc9lm33

[MERGE] merged the branch to rename the link "Purchase Orders" to "RFQs and Purchases". Courtesy of Numérigraphe

bzr revid: qdp-launchpad@openerp.com-20120216155459-6bs4beq91r6tq1xy

bzr revid: qdp-launchpad@openerp.com-20120216153533-koqnk4uev01f3g1y

bzr revid: al@openerp.com-20120216151829-3ijycoxw84bxq0ot

lp bug: https://launchpad.net/bugs/932773 fixed
lp bug: https://launchpad.net/bugs/932805 fixed

bzr revid: xmo@openerp.com-20120216150434-bnrku6qj8r10sltj

[MERGE] merged the al branch with sequence field copied from SO line to invoice line (*_layout modules)

bzr revid: qdp-launchpad@openerp.com-20120216130957-o7zwad5m4zcvotmi

bzr revid: qdp-launchpad@openerp.com-20120216130336-f68g09qk9ahlmnhm

[MERGE] merged the branch that fixes lp:919932 (duplicated account type for dutch COA). Courtesy of Stefan Rijnhart (Therp)

bzr revid: qdp-launchpad@openerp.com-20120216130028-zqt3ruyf7qloxsej

bzr revid: xmo@openerp.com-20120216123506-kp6izac28h31e0dq

bzr revid: odo@openerp.com-20120216123408-mh2htwyxf8glz450