Following 4a3fd02af4 on the portal when displaying an invoice we may get
a report_type variable (with value 'html' or 'pdf') on the portal.
This was used to not display the page number when checking the report,
but when the report is printed in the backend this report_type was unset
so the page number was mistakenly removed too.
With this changeset, the report alway know if he is pdf, html or text
and only print the page number if it is of type pdf.
opw-1924729
closes#30095
In case you are printing in html a report with minimal layout, you will have an error
since the function is not defined, but called by the onload of the body tag.
Now we don't call subst if it is not needed (and so not declared)
closesodoo/odoo#29341
This assets has a lot of JS that is loaded by wkhtmltopdf without any reasons.
Wkhtmltopdf don't like long js to load (it is why subst has been write inline)
This commit allow to print again (on slowly server) several documents in the
same pdf. Before this commit, the JS was not loaded before the default js-delay
and so the subst function never called with as result a pdf of only 1 page.
After this commit you can again print several documents in the same pdf and
subst function is applied.
opw-1909000
courtesy of @beledouxdenis that help to debug this error since it is only
reproductible on paas server.
This commit follow the same logic that commit odoo/odoo@3c61ee5
And issue wkhtmltopdf/wkhtmltopdf#2083 is not yet fixed
Survey has troubles displaying correctly the datetime picker widget
especially when more than one has to be instanciated. This merge fixes
several issues related to the datetime widget when displaying the survey
in customer (front-end like) view.
See sub-commits for more details about each change.
This merge is related to task ID 1912194.
closesodoo/odoo#28966
In survey template, the datetimepicker was created with always the same id.
So if two date fields were present on the same page, it created a
multidemensional vortex that broke an alternative reality, resulting in
not being able to fill in both date fields and other crapy stuffs.
Also, the sass file needed to work with tempusdominus library were not
loaded with the js file that comes with it. Resulting in an hugly calendar
(if it could be called calendar) widget.
As survey does not load backend nor frontend assets, it's necessary to have
both files (js and sass files) in common assets.
Task ID : 1911291
Closes PR #28966
This fix some inconsistent error on runbot.
In mobile, some views* depend on 'jquery.touchSwipe' library which
is lazy loaded. As a result, the views become asynchronous...
It's why this library is already loaded before running tests in the
mobile test suite. So we can continue to use synchronous views whether
in mobile tests or not.
But some mobile tests weren't in mobile suite...
In desktop, 'jquery.touchSwipe' is lazy loaded and the first test will
load it for others. It's why the first one has to be asynchronous:
https://github.com/odoo/odoo/commit/da7b59045d246c159f93bc75e3f19c6b1221d31c
The inconsistency comes from the fact that all tests are sequential but
we can't garantee the execution order. So, if the test mentionned is not
the first executed one, an error will occur because the view is not
asynchronous.
Now, all mobile tests are moved in mobile suite to be sure that
'jquery.touchSwipe' is loaded.
We also set the default value for size_class because we want a
coherent environment. It is very rare to find mobile devices with
more than 474px wide.
*: form_view, kanban_view, res_config_settings
closesodoo/odoo#28195
Currently, the RTL/LTR direction of a report is the language direction
of the current user printing the report.
So for example a customer invoice in french can be RTL and a customer
invoice in arabic can be LTR.
With this changeset we keep a reference to the body language and use it
to choose direction later on.
opw-1890833
closes#27878
This rev. is a complement to the partial backport 49e78f46 of
abf32b8. In addition to the helpers, we also backport the asserts
(like isVisible, containsOnce...).
closesodoo/odoo#28994
Commit https://github.com/odoo/odoo/commit/8caf84f70ada259f041b424d37686845604d182a
was not handling the case where there was an invisible DOM element
between the button box and the alert component. Let us clear all alerts.
This commit also introduces a way to properly fix/extend bootstrap in
future fixes/updates (some of our rules may already be moved in that
file once it is forward-ported to master).
closesodoo/odoo#27662
- Add a method for generating an image data URI, and expose it in QWeb context
- Fix reports, website templates or mail templates with data hardcoded
data URIs, to use the helper (Python cases), or the existing
kanban_image helper (for JS cases)
This will gracefully handle SVG support in addition to classical image
formats.
Closes#26635
Since https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242, it was possible to click on a "Shortcuts" menu item
in community which triggered a call to _onMenuShortcuts whose
implementation was only defined in enteprise
As the keyboard shortcuts are available both in community and
enterprise, we should support this menu item
* requires that current user has group_system
* only visible in debug mode (?debug)
* available at login or via debug menu
* special systray color in superuser sessions
Closes#27254
In order to ease the integration with the snailmail posting service provider,
We will generate specific reports with a layout that fits their
criteria.
In short,
* we specify the postition of the recipient's address on the
document
* we force the A4 format
This also support the din5008 type B report.
Reverting some changes introduced in
f29df7fb2e.
By changing the html tag from 'article' to 'page' we were losing the
style on the body of the document. The problem it was supposed to tackle
will be addresed in the future.
a7a89f3174 introduced a change that broke the invoice iframe.
The #wrapwrap corresponds to the client body, therefore the container must be inside it, and the scrollbar will now be on it instead of on the iframe body.
PR: #26801
task-1876864
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
Revision on https://github.com/odoo/odoo/commit/0de5c1f076d7e7d0e5361e08c810c727bd41d9e0
With the commit above, the following error was shown in the devtools
when accessing a frontend page without website that is installed:
missing module "[root.widget]"
This is caused by the fact that there is no root widget in the frontend
bundle without website installed. This may prevent executing tours
in some cases, because the tour manager needs a root widget to run.
This commit solves this issue by ensuring a root widget in the frontend
even when website is not installed, so that tour manager can run.
The <!DOCTYPE> declaration must be the very first thing in an HTML
document, otherwise you may experience that the preference is given
to the "user agent stylesheet".
This is the case while printing PDF reports using the 'minimal_layout' template.
For example, layout for 'Picking Operation' report will be different in HTML and
and PDF reports. Text inside <th> will be aligned left in the HTML report, while
center in the PDF one. The issue is there since a long time, but was not obvious
enough to catch till now. (For example, in previous BS versions, explicit rule
was present to align text to the left inside <th> tag, and so the layout did not
break by luck. BSv4 afterwards, this rule was removed, shedding light on this
issue).
This commit improves the behavior while printing PDF reports by placing
<!DOCTYPE> declraration at the very beginning so that preference will be
given to custom stylesheet over "user agent stylesheet".
Task: 1880709
Closes#26846
Before this commit, the `dom.autoresize` function may apply the
padding and border width twice when computing the height of the
textarea. This issue occurs when the fixed textarea had the same
CSS style as the textarea.
This commit fixes the issue by enforcing zero padding and border
width in the fixed textarea.
Task-ID 1882736
A new exception has been added to detect inconsistent reports. However, many are not structured as expected. Thus, the change consists mainly of checking only when the print has to be separated in part to attach it to the respective documents.
We now take the page tag instead of the article, because the article tag is in the layout, so to separate the file, the t-call had to be inside the t-foreach (for the separation) and so possibly read the assets several times. Since all templates have the first tag (in the t-foreach) tag page, the choice is more sensible.
The javascripts files used in readonly were taken out of the editing assets.
A turn was made but not activated, it works locally, but on the runbot, an error is triggered when generating assets after choosing the settings.
The goal of this commit is to fix the various views and reports of sales and invoices.
======
Portal
======
Fix breadcrumbs
Fix BS4 issues, alignment of various elements
Better auto resize of the invoice iframe
Fix invoice list for draft invoices
Fix previous/next document pagers
Remove unnecessary monetary widgets (not needed when using t-field if the field is Monetary)
Standardize invoice and sale routes:
- especially when related to displaying: html, pdf (print and download), text
- by using the get_portal_url() also for invoices
Add the total on the left column of sales order
================
Section and note
================
Improve general style:
- notes in italics
- sections: less padding, darker background, no borders
=========
Demo Data
=========
Fix sales order demo data to appear for the admin (instead of system)
PR: #25997
task-1869469
This commit adds a new js test in web that enters each app and click on
each view switcher, each menu and each search filter.
This test is tagged '-standard' and 'click_all' as it could last a long
time, that way it's not executed by default.
It could also be started from the browser console with
'clickEverywhere();'.
-Some tests where moved without addapting the path to them:
path is now update and tests fixed.
-A picture was removed in commit 4dce6cc98b but
still referenced in template website_twitter_snippet.
-A test was missing a data leading to the wrong path to image beeing loaded
This commit fixes two issues:
1. No error when running several mocked service providers in tests
Revision on https://github.com/odoo/odoo/commit/eea2366fd2b8398a6c8022f24adb722e5e16a6f4
In the commit above, the intent was to turn off the logic about
"Service Provider" in the tests environments. To do so, it was
mocking the methods to deploy services (`_deployServices`) and
the method to dispatch service calls (`_call_service`).
However, this was not enough, because such a mocked service provider
still tracks undeployed services. This is an issue in case there are
several mocked service providers running at the same time, because it
will raise an exception:
https://github.com/odoo/odoo/blob/master/addons/web/static/src/js/core/service_mixins.js#L24
Note that the tracked services are globally known by all services
providers, because the properties `services` and `UndeployedServices`
are objects that are set in the definition of the mixin.
To fix this issue, the `init` method of the `ServiceProviderMixin`
should not do anything on mocked service providers, so that they act
as if there were no service providers at all in the system. In
particular, those mocked service providers will not make changes on
the shared properties `services` and `UndeployedServices`.
2. No running services on top of benchmarks
The web client on top of the benchmark suite was not mocked in a way
to turn off the "Service Provider" logic. Similarly to the JS test
suites, services should not influence the execution of benchmarks.
Closes#26519
Before this commit, the web client in the JS tests environments
might be influenced by `longpolling/poll` or `mail/init_messaging`
RPCs. For instance, if we received a new direct message in Odoo
during some JS tests, it would open a thread window. As a result,
the tests on thread window will fail because of this newly and
externally added thread window.
After this commit, no service is deployed on the webclient on top
of the JS tests environment. This should prevent most undesirable
side-effects of RPCs, such as opening a thread window when receiving
a new direct message on the longpolling bus.
This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
warning: Some modules could not be started
Missing dependencies: web.field_utils
Non loaded modules: web.dataComparisonUtils
This commit moves 'data_comparison_utils.js' from 'assets_common'
to 'assets_backend' because 'field_utils' is only defined in
'assets_backend'.
This commit brings a Pie Chart Widget that allows to visualize
simple information on in a single pie chart.
For now it is only used in dashboard view but it could also be
used in another view that uses a basic renderer.
An element with tat widget with attribute name 'pie_chart'
can now be added to the arch view.
Three keys should also be provided in the attribute 'attrs':
- measure (determines the field to aggregate on)
- groupby (determines the field used to group data)
- title (determines the legend of the pie chart)
Task Id: 1835644
This commit introduces a new widget 'TimeRangeMenu' used in
the search view. It allows a user to easily:
- search data with a given date or datetime field value
in a specified period of time
- compare the data of interest with data of the previous
period or the previous year.
The time range menu is available in the search view when one
of the four following view types is instantiated:
graph, pivot, cohort, or dashboard.
Task Id: 1835644
Fix the issue of the t-esc display the content before the tag.
Activate qweb qunit test (same test for the JavaScript and python)
Use the same behavior as python: keep attributes order, and display content
as default value when the variable is falsy.
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
Before this change, the reports were generated in editable mode for branding
to be applied. The branding is used to cut the report and add on each
selected record for generating the pdf.
Applied branding and editing options takes a useless time and branding
was also applied by widgets even if branding was not requested.
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
Nicolas Lempereur