The Work+Sans font of google fonts was hotlinked and available in
reports since saas-14's 3d04e448.
There does not seem to be a reason to do it and:
- hotlinking may add resources usage / processing time,
- server need outside internet access or the font doesn't load,
- it has been reported to cause the header/footer of some pages to
disappear, probably because of a problem with loading the content in
a given delay to render it.
- it was always loaded for report, even if used only once among all the
reports of Odoo
For these reasons, this commit removes the hotlinking of this font.
The ISR report of l10n_ch that used this font will thus fall back on
'Verdana', 'Geneva' then the default sans-serif font which doesn't
seem to be a drawback over 'Work Sans' font.
If at one time we should reintroduce it, it should be contained in the
given report and possibly have the font locally and not externally.
opw-1861368
closes#25683
Since 11.0, reports could not be edited at all anymore. This is due to
the fact the editor files were refactored but the report feature is not
correctly organized since it was merged with the 'web' app. Indeed, the
'web' app is still calling files and assets of the 'web_editor' app which
is not a dependency (but it is working as 'web_editor' is auto-installed
with 'web').
opw-1826599
opw-1834971
Closes https://github.com/odoo/odoo/issues/24034
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).
For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.
Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).
When a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
Purpose
=======
In python2 a binary field value is retrieved as a string. Example: company_id.logo = u'xyz'
In python3 a binary field value is retrieved as a binary. Example: company_id.logo = b'xyz'
When trying to render an image on a template, we should pass a stringified version of it.
Specification
=============
Pass the method to_text in the template rendering context and use it.
- The `--no-database-list` option will now also block access to database
management functions and screens.
Presumably this flag should only be used in production when all
databases have been provisioned, so the admin should like to block
access to the db manager at the same time.
- If no `--database` or `-d` parameter is provided, the system will be
unable to fetch a list of databases at all, so users will be blocked
with an error message.
- Hide the link on the login screen to the DB manager when it is
disabled, to prevent sending users to an error page.
- Weak attempt at updating the documentation
Note: the security check for RPC methods could have been done in the RPC
dispatcher, however that would not have protected service methods when
called directly, e.g. by a controller (e.g. the dump method).
This commit refactors the JS and LESS of the new mobile version
of the grouped kanban views. It ensures that the touchSwipe
library is lazy-loaded (only in mobile, when entering a kanban
view).
This commit aims to improve the UX of grouped Kanban views on
mobile devices. Only one column is now displayed, full width. The
columns' records are lazy-loaded. The user can swipe horizontally
to navigate through columns (thanks to the touchSwipe library).
After the refactoring of the wkhtmltopdf engine, the headers/footers are managed in a very different way to be able to call wkhtmltopdf only once. The subst JS function must select the right header/footer corresponding to the current page company. However, a <div> was suppressed during the process and then, some external customization might be ignored (see github issue for more details).
-issue: https://github.com/odoo/odoo/issues/19544
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
With the new views, we lost a (almost unused and undocumented) feature:
the ability to instantiate custom widgets in a form view, not linked to
a particular field. For example:
<widget type="weekly_timesheet" attrs="{'readonly': [['state', 'not in', ['new', 'draft']]]}"/>
We reintroduce this feature in this commit, with a nice twist: it also
works for the list view and the kanban view.
Two things happen in this commit
* move portal less from web to portal. This code has been wrongly
moved to web when moving the customer portal and should be in
portal module;
* merge customer portal generic less and customer portal chatter
specific less into the same file;
We should now have only one less file for customer portal less and
located in the right addon.
This commit moves the whole customer portal to the portal module.
It now completely uses portal and http_routing features and is not
dependent on website anymore.
An override of web controller is added in portal in order to redirect
portal users to /my instead of /web. That way once having the customer
portal installed all share users are correctly redirected to their
account.
All modules defining customer portal templates and controllers are
updated accordingly.
This module adds required base code for a fully integrated customer
portal. It contains the base controller class and base templates.
Business addons will add their specific templates and controllers
to extend the customer portal.
This module contains most code coming from odoo v10 website_portal.
Purpose of this module is to allow the display of a customer portal
without having a dependency towards website edition and customization
capabilities.
Some CSS files used in frontend assets are already moved to have a
working portal skeleton. A is_public method on users is also added
as it will be used in various portal code soon.
The old behavior was to call wkhtmltopdf for each report and to put all of them together
using the merge_pdf method. It was a very slow approach because all report needs
5 temporary files, one subprocess and then, a merge.
The new behavior is to perform a single call to wkhtmltopdf by putting all the footers/headers
html together and so, avoid call to merge_pdf to greatly improve the performances of the reporting.
This commit introduces the 'rainbowification' feature to the web client
(and to some affected addons). This feature is essentially a way to
display a nice friendly message when some business event happens. For
example, a encouraging message is displayed when the user clear her/his
inbox, or when a salesman closes a deal.
The mechanism currently only displays a 'rainbowman', but could be
extended later to add other kind of animation.
There are a few different ways to display a 'rainbowman':
- any JS code can simply trigger_up an event ('show_effect') with some
options: for example
this.trigger_up('show_effect', {
type: 'rainbow_man',
fadeout: 'no',
message: $done,
click_close: false,
});
- an action returned by the server can have an 'effect' key, with some
options
- the do_execute_action method accepts a 'effect' option. This is
useful when one wants to specify a rainbow on an action button in a
form view
Joint work with: dbh <dbh@odoo.com>, ged <ged@odoo.com>
* web_editor, web_tour, website_event_track
Before this commit, one JS file was responsible for all the library
extensions and fixes. There were two main problems with this system:
- The file was only available in the backend (as some extensions are
made on backend-only libraries).
- Some other modules were doing library customizations.
This commit creates one file per library to regroup their associated
customization and adds them in the right asset. These are placed in
the web module and every other module should avoid doing customizations.
This allows to have libraries consistency accross all modules and
between the backend and the frontend.
In the list controller, some code to determine the active domain to
export was causing a crash. It was easy to see: just select all records
in a list view, then click on 'Export' in the sidebar.
Note that the data_export code is still quite old, and did evolve
organically. It does not conform to our new design principles, in
particular, the way component should communicate. But this is a task for
another day.
With this commit, we introduce a benchmarking infrastructure: a new
controller, accessible at the route /web/benchmarks which will render a
new template (web.benchmark_suite).
This template uses benchmark.js and qunit.js to display a list of
benchmarking informations. For example, the number of op/s for
instantiating and destroying a list view.
I hope that this is the start of the beginning of taking the habit to
check our JS code performance sometimes, and making sure we do not have
large regression without a good reason.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
We changed the do_action method recently: before, it was calling
recursively its parent, now it simply triggers up an event. We also
moved it to the 'services' mixin. However, we did not properly connect
the 'on_success' option: it is not an option for the view manager, but
for the abstract web client. As such, it should not be in the options
parameter, but it should simply be a key in the event payload.
This commit was found by solving the two following issues:
- open sale application, click on 'Inbox' icon to go to discuss,
Discuss is opened, but the navbar stays with sales application
- after installing module website_crm_partner_assign in kanban view for apps,
it does not reload...
Both of these were caused by the need to do something after a do_action,
and the deferred was not resolved at all.
The views can specify js (and css) libraries to lazy load when
they are instantiated for the first time. The previous
implementation was too naive as it always loaded the specified
libraries in parallel. However, it may happen (e.g. gantt view)
that some of those libraries depend on other ones.
This commit implements a mechanism to handle libs dependencies
between each other. For instance, specifying:
js_libs: [
['a', 'b'],
['c'],
],
will load 'a' and 'b' in parallel, but wait for them to be
loaded before loading 'c'.
The new implementation still supports the old syntax. So,
js_libs: ['a', 'b', 'c'],
will load 'a', 'b' and 'c' in parallel.
Nicolas Lempereur