In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.
The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed. With the
extra size class, this number was undefined, which caused an issue.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.
The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed. With the
extra size class, this number was undefined, which caused an issue.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
Purpose
=======
The method compute is annoying for the following reasons:
- 'compute' is difficult to grep
- Developers don't understand that they can specify the company and
the date on which we want to convert the amount. This is quite
error prone because if these parameters aren't specified, they are
set by default to the company of the current user and the current
date (today).
- Passing parameters is the context is not a correct way to call a method.
Furthermore, using with_context is not really good for the performance too,
as the record as to be rebrowsed, the computed fields have to be
re-evaluated
Specification
=============
- Introduce a new method '_convert'. This method takes 2 more
parameters: 'company' and 'date'.
- Deprecate 'compute' and '_compute'. Log a warning to notify that we
should use '_convert'.
Revision on https://github.com/odoo/odoo/commit/32b8cec5361174c92c45a4975d4e02f1fb448aa2
Before this commit, when we switch channels in the Discuss app, the breadcrumb
was visually not updated: it keeps the name of the first opened channel.
With this commit, the breadcrumb is updated on each change of channel, so that
it displays the name of the currently opened channel.
Technical details:
This is due to a change of logic of updating the GUI of the breadcrumb:
before the refactoring above, discuss had to pass the content of the
breadcrumb to the control panel, in order to update the breadcrumb visually.
After the refactoring, the action manager should warn the control panel to
update the breadcrumb on any change of the title. This is already the case
for `ir.actions.act_window`, but not for all types of client actions.
When Odoo display a phone number number, on phone or if VOIP is
installed a invisible `­` character was added from 9.0 up to
saas-11.2 so an applications such as skype would not be concerned with
the number.
But if someone copy-pasted from this to somewhere else in Odoo, we would
get incorrect number with this invisible caracter. So this change make a
special case for the "FieldPhone" so the character is removed from data
saved.
opw-1834858
closes#24223
Before this rev., a crash occured when a default_get returned a
command 0 (CREATE) for a one2many, with a value for a date(time)
field (e.g. [0, false, {some_date_field: '2018-12-08'}]). This
was because the related values (inside the commands) weren't
parsed. This only impacted date and datetime fields, for which the
parsing converts the string into a moment instance.
Fixes#23672
The built-in Odoo profiler can be used directly into the logs. This
information was not given in the documentation. This commit add it. An
example on how to use is shown as well as the produced result.
Have the create_date field displays on a one2many list
Try to add a record onto the list
Before this commit, when the virtual record is added onto the list
it crashes because the datetime field is undefined and cannot be parsed
After this commit, It doesn't crash though the value would have to wait the save on the main record
to be updated (because it is the create_date)
OPW 1834250
closes#24097
- Go to Timesheets > Add a Line (grid view)
- The view opened is `view_timesheet_form`
- Add a description with several lines
- Go to Project, and display the timesheet entries.
- Print the report "Timesheet Entries"
The lines in the description are merged into one single line.
Since it is possible to write a description on several lines, the report
should keep the formatting.
opw-1830703
Recently, rev. 5b3cb812b added a new custom event ('update_filters')
handler to the ActionManager, and rev. 69c9500 added an option
('keepSearchView') to doAction (which can be called by triggering
up event 'do_action').
Both events ('update_filters' and 'do_action') can be triggered by
controllers, and when those controllers were in the dashboard, a
crash occured when they triggered those events. In particular, they
are triggered by the new 'web_dashboard' view, respectively when
clicking on an aggregate and when clicking on the subview button to
open it full screen.
The crashes occurred because the events weren't intercepted by the
dashboard, so they bubbled up to the ActionManager which couldn't
handle the requests properly as it wasn't aware of those sub
controllers.
As there is no search view in the dashboard, the 'update_filters'
event simply needs to be stopped (we can't handle such a request
in the dashboard), and for the 'do_action' event, the
'keepSearchView' option must be forced to false as there is no
search view to keep (we thus force the ActionManager to create a
new one).
Instead, create a new BoardView (in JS only) instead, referenced by
specifying js_class="board" on the fly on the root node of the
arch of the board view.
This ensures that the dashboard addon doesn't impact the FormView,
and this is necessary to ensure that the next commit doesn't break
anything.
The former version of the tax adjustment wizard was copying the selected tax on both the credit and debit line of the created journal entry. Although it was fine for the belgian use case (since the report was taking only the sum.debit or sum.credit to gather data for grid 61/62), this was a stupid limitation as it was preventing to use that wizard to touch any grid using sum.balance (as both lines would be taken into account and cancelling each other).
To enhance/fix this, we introduce a fields.selection in the wizard to depict if the tax needs to be copied on the debit OR the credit line.
Inspired by ticket 1826242.
When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`
When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.
Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.
Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).
This commit is a cherry-pick of 802339c12d
and dcca2e8b9d
In arabic, with the version localization of bootstrap we use the week
starts on saturday. But the version of bootstrap-datetimepicker we use
in 10.0 and saas-14 is 3.0.3 which only fully supports week starting
on sunday and monday.
Thus in arabic, the column title in the date picker would be:
Sunday <- Monday (ﻥ, ﺙ, ﺭ, ﺥ, ﺝ, ﺱ, ﺡ)
Instead of what the numbered days in the calendar are shown as:
Friday <- Saturday (ﺱ, ﺡ, ﻥ, ﺙ, ﺭ, ﺥ, ﺝ)
This issue doesn't happen in saas-15, 11.0 and over since the library
has been updated with ad6fd5f8 and the as of version 4 supports any
starting day of week, with this change:
https://github.com/Eonasdan/bootstrap-datetimepicker/commit/557b657
opw-1825640
closes#24200
In 93147fb4 the issue that only one page of barcode were printed was
solved.
But there is still an issue since the container element is itself a
page, we got an additonal page with all barcode on it.
To solve this we use a 'report.html_container' instead of
'report.basic_layout' which doesn't wrap the content with a
`<div class="article" />` element.
opw-1827673
closes#24201
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
In Less, the size_class XL is now defined and can be used in media-queries.
It is also added in JS for the sake of consistency.
This new size is needed for a fix in enterprise.
Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Note: original work of @dbh-odoo was to have + and - buttons on the
editor overlay but specs changed to use a standard dropdown (the work
of @dbh-odoo was thus adapted for this).
See task-46094
Closes https://github.com/odoo/odoo/pull/22197
In Less, the size_class XL is now defined and can be used in media-queries.
It is also added in JS for the sake of consistency.
This new size is needed for a fix in enterprise.
Seems like this tour crash randomly due to default 10000 ms.
This button, in some case, seems to take more than 10000ms (slow server? slow
connection ?) to validate the order (cretae invoice, generate PDF, send mail, ...)
It is a test to see if increase the timeout could decrease the risk of false
positive on the runbot.
Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
The sale_note field is translated according to the language of the customer in a SO.
This fix applies the same behavior on the customer invoice.
Inspired from this commit: 978b8f64ec
opw:1830838
Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
Before this commit, an error was raised when you tried to create a
new bill of material on a new manufacturing order.
In fact, the name_create RPC returned 'false' and slow_create()
wasn't executed.
By adding _rec_name (as in 10.0) on the corresponding model, the RPC
call will raise an error that will be caught by quick_create and
forces slow_create().
Closes#9761
Before this fix, when navigating with LEFT and RIGHT keys on a grouped
kanban view, if there were empty columns in the direction of the
navigation, the focus did not change to the next column.
After this fix, the navigation left and right ignore empty columns and
jump to the first non-empty column.
Before this fix, list view and kanban views are scrolling every time
the user uses the up and down keys.
After this fix the list and kanban views will only scroll when the user
arrives at the boder of the window
Inside the cell of a table, indenting had several behaviors:
- if the selection is contained in several nodes elements: indent the
element child nodes of common ancestor
- if the selection is contained in one or more list items: indent these
list items
- if the selection is contained in one 'content block': indent the whole
cell content
The two first behaviors are expected, but the third one is a little odd
and unexpected next to other existing editors behaviors.
With this commit, the third behavior becomes:
- if the selection is contained in one `content block`: indent this
content block
note: 'content block' is defined as p, pre, h1, h2, ..., blockquote, td
opw-1824647
closes#24182
The website_url wasn't defined on the project.project model.
However the website pager expected this field to be defined on every model it
worked on.
Without it, the webite frontend would throw an error 500 while trying to access
this field.
Note that the website_rating_project_issue would add this field anyway to
project.project by making it inherit website.published.mixin. The bug would thus
only appear if this module was not installed.
opw 1832994
Properly change the color of the note using variables and avoid getting
50 shades of grey in the less variables.
Increase a bit the border bottom to mark the difference.
The note vs message rendering should still probably be improved as changign the
background is a bit confusing but in the meantime, the difference is visual
enough.
If a user is in an early timezone (e.g. UTC-5), an order made on the
...-01 19:15:00 or, converted to UTC, as ...-02 00:15:00
fields.Date.today() returns the days ...-02 instead of ...-01
Use context_today to convert in the right timezone.
This slightly change the return format of _payment_fields to return a date
instead of a datetime.
Followup of 7272abe0e3 that was adding the timezone in the context
Closes#22651
Before this commit, the field validity_date was missing from the
default quotation report. Historically this field was added in
module website_quote but it was then moved to sale in
77bd5181f7
The modification on the quotation report related to validity_date
were missed at that time.
This commit adds validity_date to the default quotation report.
The commit 1ba4fbe640 did not match the specs of the task, but
was merged anyway. Reverting the commit, and check by default so the
user is not confused with missing fields.
opw-1824074
Consider the following scenario involving a one2many list (non
editable) inside a form view:
- click on 'Add an item', a model opens,
- fill the fields and click on 'Save & Close',
- reopen the freshly created record,
- maybe make some changes (this is optional, but makes sense),
- click on 'Save & New',
- fill the fields and click on 'Save & Close',
-> the second created record isn't added to the list.
The problem comes from the fact that when the dialog is opened for
the second time (in this case by clicking on a record), the 'save'
handler registers an 'UPDATE' command. While this is correct for
the 'Save & New' click (as we update an existing record), this
isn't for the second record which doesn't exist yet, and thus
requires an 'ADD' command.
This rev. ensures that the two cases are handled in the 'save'
handler given to the dialog.
OPW 1829723
Géry Debongnie