* 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.
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
In method `user_has_groups`, make "Technical Features" effective in debug mode.
Make the group "Employees" inherit "Technical Features".
Make the group "Technical Features" invisible in the user form view.
Remove useless `ir.rule` attached on group "Technical Features".
Fix `test_acl` by avoiding the tricks around the group "Technical Features".
* added intermediate ``_read_file`` step dispatching between CSV, ODS
and XLS(X) parsing
- primary dispatch on mime type, secondary on file extension:
+ OS may not provide a relevant mime type if no software locally
installed for the filetype (e.g. Windows sends excel files as
application/octet-stream if excel is not installed, and ODS files as
zip if OpenOffice/LibreOffice isn't installed)
+ applications may re-register extensions to non-standard mimetypes
breaking the dispatcher
So if the mimetype is found trust it, otherwise try with the
filename's extension (if any)
- all readers skip lines with only empty cells in their output
- ODS and XLS content are "CSVified", rows are converted to arrays of
unicode strings
* UI altered to not assume CSV files everywhere, and avoid returning
garbage preview data for non-CSV imports
Various:
* added a ``can_import`` utility function to tests.common, can be used
to skip tests if an optional Python dependency is not installed (but
one would like tests to run if the dependency is available)
* fixed datetime issue in ir_fields
* added converter for monetary fields (iso float)
* spreadsheet don't have integers, twiddling required to ensure integral
values won't be serialized as floats (breaking conversion back to
Python)
* improved some tests by asserting no error is generated (bonus: logs
the error message if there is one, rather than just saying the result
is blown)
* because some systems only provide elderly versions of
XLRD (e.g. current debian stable provides 0.9.2 from April 2013)
- keep using xldate_as_tuple instead of 0.9.3's xldate_as_datetime,
workaround is simple
- check for xlrd.xlsx in case of pre-0.8 XLRD
Authorship:
Ronak Baxi <rba@odoo.com>
Mohammed Shekha <msh@openerp.com>
Task 10792
Closes#7285
- Use the ControlPanelMixin in the Import view;
- Adapt the stylesheet to fit with both community and enterprise editions;
- Convert the css into less, use mixins and variables defined in web;
- Return the reload() deferred in the on_reverse_breadcrumb callback so that the
previous action waits to be properly reloaded before being shown.
When importing csv data, the column name is matched on the field name and string
attribute. For some fields (e.g. name & display_name), you could get a match on
both the string and technical field name for different fields
The order of the fields is not deterministic as stored in a dictionnary so
different results were possible at different import.
The technical name should be prioritised (more stable, unique constraint).
Fixes#6657
If you try to import a file with a header 'Parent_id/id'
_match_header will not match Parent_id with parent_id
because it was comparing with case sensitive.
It's not a bug, but in most cases this new behaviour (non
sensitive case search) is what the end user was expected.
Hate Excel and the auto correct capitalization !
Odoo Translation Bot