In mobile devices, the pad widget did not behave in a satisfactory
manner. Also, once it was in fullscreen mode, it was not possible to
come back to normal mode.
Task: #31545
PR: #15817
Up to this revision, clicking on 'edit' in a record with an existing pad
and discarding the changes straight away caused the pad content not to
be displayed.
The root cause of this issue is twofold:
- a hack tricks the model into thinking the pad URL has changed by
replacing it with an object yielding the URL when JSONified;
- the pad never affects the 'dirtiness' of a record and BasicModel only
actually discards changes when the record is dirty.
When a user clicks on discard, the model does not actually discard the
changes, thereby leaving the web client into thinking the pad URL is the
object mentioned above.
We fix this issue by requiring that the model always discard changes
when clicking 'Discard', regardless of whether the record is dirty.
In fact, the lines we changed were no longer correct since the
introduction of 'doNotSetDirty' (see
https://github.com/odoo/odoo/commit/72ed3a1), as a record could be
changed without being dirty. This commit thus also ensures that such
records are also properly discarded.
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
Before this commit, the pad widget did not force the view to save the
current value, since it did not change (pad values are just the url for
the pad). However, this is a problem for the server, since it uses the
fact that the web client forces a save to update the description field
in the model (get the data from the pad server and add it to the
database).
This was not a big deal when looking at the pad (the pad widget fetches
its data each time), but it is a problem that the database is not
synchronized with the current data.
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
Before this fix, it was possible to set the widget 'pad'
on char fields but it only worked if the current model
inherited from 'pad.common'.
In the other cases, it crashed on closing Studio.
As there is two models only (project.task and
note.note), we decided to remove the possibility to set
this widget in Studio.
opw-745997
The pad widget was partially updated to the new views, but was no longer
working. In this commit, we rewrite the widget to make it work.
Note that we did some functional changes:
- we do only one rpc to check if the server is configured. the result is
stored on the prototype, so we do not need to do it again
- we do some rpcs with shadow: true, so we will not stop the rest of the
ui if the server is slow to respond
- we display a loading message in readonly, when the content is not
loaded yet.
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
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.
In the form views where the pads are used, Etherpad-lite automatically
focus on the pad content, even if the user has already started to type
into another field.
This behavior is quite annoying for "quick changes", so we provide a
(very tiny) plugin for Etherpad-lite that will prevent this autofocus.
Detailed installation instructions are also included.
Added a small method to detect the proper server configuration,
and make it degrade gracefully if the method is not present.
This avoids having to force a pad URL generation in order to
test the config (possibly creating useless pads).
Add a user-friendly message when the pad has not yet been
initialized for a given record, in read-only mode.
bzr revid: odo@openerp.com-20140314131849-rnjvk1pqpiyvtc1c
Viral Thakar