This compatibility file reexports every symbols from the modules to the
old openerp namespace. The goal is to allow old unconverted odoo addons
to interact seamlessly with the new web client.
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
These two addons were doing evil things with the way registries works.
1. they create a new registry to add something in it,
2. they replace the existing reference with another
3. they don't use the "add" method.
Seriously, original coder, what were you thinking?
being able to create and write on many2one and many2many records in a form view.
Indeed before this commit users had always the possibility to create or edit records
leading to a crash if no access rights were granted. Now the option is
not displayed if the user has no rights to do it.
Tests have been added for this feature.
invoice_exists field has been removed, because invoice_count can be used when the
old field was used.
invoiced_rate field has been removed, because it was never used except in a
test.
Also added a stat button with deliveries on sale order.
The test for account followup use UTC time, but the default `date_maturity`
and `date_due` of an account invoice come from fields.Date.context_today`.
One failing test for project_timesheet also used `today` instead of
`context_today`.
So depending on the test user timezone, an error of one day (if UTC time
and user time are on different day) occured which failed the tests.
For example:
* user has GMT+1 timezone, test fails 0:00am–1:00am (11:00pm-0:00am in UTC)
* user has GMT+3 timezone, test fails 0:00am–3:00am (9:00pm-0:00am in UTC)
This fix removes UTC use in the tests.
The quick create popup tried to look up the parent's .string and
.name (or the parent's field_widget's) *but* the calendar view didn't
have a .string, and its .name gave priority to the view's name (as
returned by fields_view_get) as opposed to its @string.
Store the view arch's @string to CalendarView#string, so the quick
create dialog can find and use it.
Replace jquery-ui dialog by bootstrap modal
* fixes general styling (jquery-ui styled heading)
* fixes z-index stacking (jquery-ui dialog appeared on top of
"slow-create" boostrap modal)
* fixes disappeared close button
when a customer invoice is created directly,
if a product variant is selected,
it now computes the price from the product variant and
not from the product template.
opw: 629285
The menu was not present in 8.0 when going back from the mass mailing email
composer to the backend. This fix adds the current action id as a return_action
query string parameter and return to the correct action.
fixes#5591
opw-629526
When a message had no author (this is accepted),
a recipient without full_name, name and email address
was added to the suggested recipients of the thread,
leading to a "(no email address)" within the suggested recipients,
which is not really useful.
opw-629797
This patch hopefully solves an annoying issue with the search view:
when the user types really fast (or uses a barcode scanner for example),
the resulting search string was (sometimes) missing the last few
characters. I'm unclear on the exact reason why it happens. From the
code, I can only guess that it happens because the scanner use a TAB
key instead of ENTER (TAB is handled in keydown event, ENTER in keyup),
or that the key events aren't in a correct order (if the user press a
key A, then press ENTER, then release ENTER, then release A, it results
in an empty key).
Anyway, the way this patch probably solves the issue is by using the
keypress event for triggering the search view. I hope that in every
case, the keypress event are correctly ordered. It leads to some code
I'm not really proud of this patch, but the key event handling are
quite messy. Also, I need to handle the search string also when the
keyup event is fired, because it might change the search (for example
backspace trigger a keyup, but not a keypress).
Géry Debongnie