Use case: create a new tag, change its color and create another new tag. The m2m field was rendered again but the dataset was not aware of the color change on the first new tag. We need to invalidate the cache after changing the color in a tag in edit mode.
- Remove _check_communication method which was a complex way to achieve
what extension classes can do with a simple @api.constraint
- Proper default values for partners created through the payment form.
- In res.partner.bank, store the 'acc_type' computed field so that it can
trigger constraint check (base_iban adds one)
- Misc
* make CSRF protection the default on all non-SAFE methods
(any method besides GET, HEAD, TRACE and OPTIONS )
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get
the CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before
hashing/validating the CSRF token
* opt-out database manager from CSRF: the super-admin password
serves the purpose of a CSRF token in the database manager screens.
Implementation by xmo@odoo.com and chs@odoo.com
Only used by web tests (which rely on a module they don't depend on to
run, bad!) and altering the test session directly should work, so this
endpoint seems completely unnecessary.
* add CSRF token as core.csrf_token
* add CSRF tokens to client-generated and/or JS-submitted forms
* remove broken "compatibility" mode of web.ajax.post
/cc @dmo-odoo I've no idea how that was supposed to work, from looking
things up all modern browsers seem to support FormData, and old IEs
which don't don't support fallbacks either and would require
submitting an actual form as fallback so...
* make CSRF protection the default on all non-SAFE methods
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get the
CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before hashing/validating
the CSRF token
* opt-out database manager from CSRF: The super-admin password serves
the purpose of a CSRF token in the database manager screens.
There is no request database to obtain the
secret and generate a CSRF token.
Unfortunately Ubuntu LTS does not have passlib 1.6 yet,
even though Debian Stable has it now, so for the sake
of making life easier for everybody we'll stick with
passlib 1.5 for one more version.
This reverts commit c950224ef7.
This field is broken since 230e12b in 2011 (return value to inexistant 'basic'
key). As it was never used and not working, remove it.
Closes#8781Closes#8785
Debian Jessie provides Passlib 1.6 so we're not bound to 1.5 anymore.
Use 1.6's "deprecated=auto" feature: will automatically mark any hash
other than the default as "to update" rather than having to list all of
the supported hashes to deprecate (and remember to update in lockstep
with the schemes list).
When not specified explicitly, the default hash is the first one in the
schemes list.
As the link between moves and operations is done for every quant,
we can do all links between a same operation and move at once.
Besides helping in performance, this fixes problems to handle all the lots
at once for one operation.
The views for pack operation lots are also refined.
In qweb reports, the address is displayed according the standards of the
country where it belongs. In the email templates, the company address was
always displayed in the same way, no matter the country of the address.
Rename 'Serial Numbers' menuitem into 'Serial Numbers / Lots'
Move Ugly Unpack button on the header in stock.quant.package form view
Remove doublon menuitem for action 'product_uom_form_action'
The template had been previously dropped by mistake.
+ the validation buttons were not correctly handled and so changing
his password was not possible (these buttons must be in the modal
footer).
Martin Geubelle