If the method `import_file` is called with the new API, the context is a
frozendict and the update will raise `NotImplementedError: 'update' not
supported on frozendict`
closes#5798
The sequence for new items in some models is simply set to a constant 10.
Hence if 3 items had after reordering sequences 10, 11 and 12. If a new item is
added, it would get after saving at the second position.
This fix set the sequence of a new item to the maximum+1 or minimum-1 sequence
of current items sequences (max if tree has editable="bottom", min if tree has
editable="top").
opw-627830
database manager is the only html file we have, and because of that,
regularly escapes the greps. It was still trying to load old files
before the javascript modules. It has now been updated to the new
file structure.
Also, I had to guard the nv customization from happening in misc.js
because the nvd3 library is not loaded in the database manager, but
the misc.js file is required. Not really happy about the misc.js file,
but this is for another commit.
This will allow to speed up our migration platform: as funzip can pipe
the output of the first file of the archive, even if the file is not
fully unzipped yet. This is useful to plays with dump.sql without waiting
for the full archive decompression.
When a `noupdate` record is processed during an update,
the update_dummy method marks the record as "seen" so
it won't be deleted at the garbage collection step,
and seen as an obsolete external ID.
This needs to be done also for the parent records via
_inherits, because they have also received an implicit
external ID at creation, and must not be garbage
collected, even if their `noupdate` flag (db side)
is not set because the flag was added later.
This rare problem could be reproduced by creating a product
in a module, then referencing it in e.g. a sales order,
then updating the module after changing the product
record to be in a `noupdate` block.
At the end of the update the implicit product.template
record would be garbage collected, and trigger a cascade
deletion of its children - blocked by the SO reference
to the product.
This temporary patch was used to simulate the presence of a
`display_name` field in all models. It is not needed anymore
as of version 8.0, which comes with the actual magic to make
`display_name` work everywhere.
Improve commit bf31ab6718:
- do not use the product.product name_search() when there is no
search term (it's only useful with a search term
- do not use the product.product name_search() when the extra
domain (args) has a criterion on IDs - these will be *template*
ids, not *variant* ids, so the results would be wrong
- Since templates and variants use a different natural `_order`,
perform an extra name_search() on templates after gathering the
ids to return, to apply the proper sort ordering. Increases the
penalty by doing 2 name_search() calls.
This issue could be seen e.g. in the breadcrumbs where the
display_name variable is displayed for templates, and indirectly
relies on name_search() due to an old hack in call_kw in order to
implement the "future_display_name".
This branch introduces a new module system for our javascript
code, inspired by requirejs. It is a really large change,
since all the javascript code had to be updated to use the
new system.
Some important remarks:
* the openerp global variable has been deprecated. Do not use
it in the future
* a new global variable has been introduced: odoo. It contains
the 'define' function used to create new modules. Use it
to create modules, not as a global bag of things.
* the web client code has been refactored. Most files have
been split into smaller files. The code should be easier to
understand now
More documentation can be found at:
www.odoo.com/documentation/master/reference/javascript.html#web-client
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
Arthur Maniet