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
Remove part in service_mixins who hide this error. Queries must be able
to be canceled for better performance. Also in the case of longpolling,
if the request is not canceled, wait for a server message or the maximum
time (30 sec) to add or delete channels.
Browsers add a 1px padding to inputs but they don't do it for the
select elements, which makes them unaligned.
Tested under Chrome 68, Firefox 61 and Safari 11 on MacOS 10.13.6.
When cliking on a calendar cell user is redirected to a form view to create
a new record. However if the calendar action gives a specific form view ID
it is not taken into account by calendar.
Calendar code still handles views as not being a structure holding viewID and
type but just an ordered list of items with (view ID, type). This commit fixes
that code. One calendar JS test is updated to correctly match the current
structure.
This commit is linked to task ID 1876795 and PR #26571.
CORS error was firsly fixed with 4bd8e3e2ed in 11.0
Then it was cherry-pick'd and improved in 10.0 with 9f1438d5f1.
But the improvement was lost during forward port from 10.0 to 11.0.
This commit adds the lost fix.
Closes#26812
This allow the browser/device to handle the experience of handling number in a more native way.
FieldInteger and FieldFloat now inherits from NumericField because we want
to format it or not dependent of the view (readonly or edit) and the
NumericField will manage it.
We do that because input type number can't take a value with comma on Chrome
(FireFox is more permissive but not perfect because comma is the separator
for decimal in this case).
Task #1880376
-removed force_ext from ir.http.
-added signature arg to web/image to differentiate cache entries by URL.
-added an embed youtube viewer for youtube URL's
-added a PDF splitter to the PDF viewer UI
-added tests for mail's Document Viewer
-added a "signature" param to web/image to go around the browser cache
-thumbnail field of ir.attachment is now stored in the filestore
as a distinct attachment.
task 1853490
Co-authored-by: Pierre Paridans <app@odoo.com>
Up until now, the execution of a report action could not be followed by
any action which prevented, for example, to automaticcaly close a modal
after printing a report from it. This has become an issue when working
on customer's invoices using the new modal introduced in 4cb9194275
This commit allows to close a modal after the download of a report.
Removing the code that allows to generate multiple reports with a single
action introduced in 410d6a703b as it was
only used for l10n_ch and that this was abandoned in
5169b50efe.
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.
This is because in the refactoring adding modules (e8a00bc50d) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.
But there was still an usage of the removed implementation.
opw-1880766
closes#26816
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
Since rev. 960360af, Date (resp. Datetime) fields return
datetime.date (resp. datetime.datetime) objects. This caused an
issue in the read_progress_bar method which returns a dict, whose
keys are values of the group_by. Indeed, when grouped on a Date or
Datetime field, the key was no longer a string but a datetime.date
or datetime.datetime object, and it crashed when that dict was
turned into a JSON string.
This method isn't tested at all for now, but tests will come
shortly.
Task 1878254.
Rev. 279d928693 forced
`server_wide_modules` to include 'base' and 'web', because both contain
controllers that need to be always loaded.
However the patch used a set() that randomized the order of the list,
when combined with Python 3.5's randomized hash function.
This is turn could cause the checksum of asset bundles (web.assets_backend)
to randomly vary, which could cause rapid assets recycling and errors.
The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
Let's assume a quick create form view with an onchange. Before
this rev., if the user set a value for the char field with
onchange, then clicked on 'Add', the record was created before
the onchange was applied, and thus with incorrect/incomplete data.
The reason is that, when clicking on 'Add', the user triggers a
'change' event on the char field, which notifies the model of its
new value. Then, as 'Add' is clicked, the quick create widgets asks
all widgets to commit their potential (uncommitted yet) changes.
But there is nothing left to commit as the changes have just been
notified. The quick create only waits for this to make the create
RPC, and thus totally ignores the changes that were committed at
the first place.
Task 1878254.
This rev. adds a new function to the mutex concurrency helper:
'getUnlockedef'. This function returns a deferred resolved as soon
as the mutex has no more task to execute (or directly if it is
currently idle).
Such a function was needed for an upcoming fix.
Related to task 1878254.
Before this rev., if the user clicked several times on 'Add' (or
pressed several times 'Enter'), on a KanbanQuickCreate record,
multiple records were created.
This rev. makes sure that this doesn't happen anymore by locking
the widget when it is creating a record ('create' RPC that might
be preceeded by an 'onchange' RPC).
Several test cases are added, to mock the different scenarios that
could occur, as they are all slightly different (depending on if
there is an onchange or not and if the user clicks on Add or press
Enter).
There is still a scenario that needs to be handled, which is the
one with an onchange and where the user clicks on 'Add'. This one
is more tricky and will be handled by a future commit.
Task 1878254.
This rev. removes a deadlock situation that could *theoretically*
occur, but that was actually hard to reach in practice.
Before saving a record (e.g. in a form view), all field widgets
are asked to commit their value (in case they wouldn't have
notified the model yet, e.g. because the user just changed them).
For instance, let's assume that the user fills an input field, and
then triggers the save. In practice, by triggering the save, it
will force the widget to notify the model of its new value (because
it looses the focus). This is also the case using keyboard
navigation, as it actually simulates clicks. So when the widget is
asked to commit its value right after, it has nothing more to
commit.
This is fortunate, because if it actually had something to commit,
we would end up in a deadlock ('commitChanges' is executed in a
mutex, and if the widget triggers a new value, '_applyChange' is
called, and is executed in that mutex as well). In fact, executing
'commitChanges' in a mutex is useless, as '_applyChange', which is
called when a widget has something to commit, is already executed
in the mutex.
So this rev. removes the use of the mutex in 'commitChanges'.
Doing so broke several Many2One tests, because they wrongly relied
on the presence of the mutex for scenarios where the user quick
creates a relational record, and then directly saves (before the
relational record is actually created). We thus handled that
usecase properly to make the tests pass.
Task 1878254.
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.
This commit changes two things in the time range menu
appearance:
- the order of range options
- the spacing between them (now two different groups
are separated by an empty lines)
Some tests had to be changed accordingly.
This commit fixes a bad behavior of the pivot view. By the
past, if there were no data to present in the pivot view, no
information on the pivot view configuration was returned by
the get function. This does not cause problems to the pivot
renderer (by design) but causes problems elsewhere, for
instance in a dashboard view that contains a pivot view.
Indeed, at each update, the dashboard view reinstantiates its
subviews, so that information can be lost if a subview is of
pivot type.
The _mergeData function used in pivot view comparison mode
was not designed to accept the absence of the __count key or
null values for measures in the objects returned by a 'read_group'.
The absence of the __count key would result in a traceback and null
values for measures into wrong calculations (infinities).
One could ask why null values did not cause problem before.
The simple reason is that the formatters used to format cell values
render a 'null' value like they render a zero.
This fix makes explicit that null values have to be considered
as zeros and avoid in that way Infinity values when computing
variations.
The search view in mobile mode has been redesigned and looks a bit different
from the search view in desktop mode. This commit adapts the time range menu
appearance in mobile mode.
Exporting data of a pivot view in comparison mode ends in a
crash. The root cause is that _t was replaced by _lt
so that some strings were replaced by objects with a toString method.
This does not cause problems when rendering a pivot view since
both QWeb or JQuery call that method. The function _exportData does not.
This commit fixes that situation and adds a test of _exportData.
The buttons 'Flip Axis', 'Expand All', and 'Download xls' are
now deactivated when no data are displayed in the pivot view
(those buttons are useless in that situation).
- Activate lots and SN
- Go to Inventory > Inventory Adjustments
- Export a record
- Select the field 'Inventories > Lot/Serial Number'
The `name_get` of the field is exported, not its XMLID.
This is because the parsing made in order to limit the depth of export
is made on the label, not on the field name.
Actually, it is not clear WHY this limitation exists, but we keep it for
compatibility purpose.
opw-1877092
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes#26676
Dharmraj Jhala