- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
In the filters menus, the order of groups of filters comming
from the search view arch was not always preserved in the filters menu.
This commit fixes that situation.
forward-port of @4094f755
This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.
Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:
- date: string.
A valid field name with associated type date or datetime
- default_period: string (optional).
To choose in the following list:
- 'today'
- 'this_week'
- 'this_month' (default)
- 'this_quarter'
- 'this_year'
- 'yesterday'
- 'last_week'
- 'last_month'
- 'last_quarter'
- 'last_year'
- 'last_7_days'
- 'last_30_days'
- 'last_365_days'
Example:
<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>
Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.
In this commit, we implement a function which allow to combine
a list of domains into a single normalized using a 'OR' or an
'AND' operator.
We also refactor slightly py_utils.
In this commit, we implement a function which format a py.js abstract
syntax tree into a string. This is really useful whenever we need to
manipulate python expressions.
The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.
Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.
Some functions that were in web.pyeval were actually "odoo independant".
To make them easier to manage/understand, this commit move them in the
library py.js, as an extra file.
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
Before this commit, the kanban view ignored the fact that a field widget
could be asynchronous. Worse, some preliminary support was done in
kanban record, but this would crash if an async widget was used.
With this commit, we properly synchronize the kanban
records/columns/renderer. If for some reason a widget needs to be
added to the DOM before it is ready, it can simply returns an empty
value in the willStart/start methods.
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
Description of the issue/feature this PR addresses:
Accessibility improvements forbids the use of the syntax
`<i class="fa fa-check"/> Some text`
to create a labelled icon. But, by this, some fonts are changed.
Desired behavior after PR is merged:
The old syntax can be used.
Have a view with a field as:
<field name="stuck_in_the_middle" attrs="{'readonly': [('with_you', '=', False)]}"/>
Before this commit, the contents of attrs were parsed and merged into the modifiers
and the attrs attribute of the node was deleted
which might cause divergence between reality and tests
After this commit, the mock server does what the server does in this case
closes#25583
Steps to reproduce the bug:
- Go on a SO and click on "Send by email"
- Remove the attachment and click on "Add an attachment"
- Choose an attachment A and remove it by clicking on the cross
- Click on "Add an attachment" and choose the attachment A
Bug:
The attachment didn't appear in the modal.
opw:1862482
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
This fixes the following bug:
Creating an Invoice, clicking on Validate (with no invoice line), and then trying to add a product.
Before this fix, this would throw an error message.
Now it works.
The sequence had a static default value, but when there is an handle, it's important that new items are added at the top or the bottom of the list.
This is a rare case where the defaul_get from the server will be ignored by the view for a certain field.
This will work:
- both in editable mode (inline) and in dialog mode,
- both for X2Many and standalone list.
The scenario is:
- create a new parent model, which has a one2many
- add at least 2 one2many lines which have:
- a handle field
- a many2one, which is not required, and we will leave it empty
- reorder the lines with the handle
This will call a resequence, which calls a name_get.
With the bug that would throw an error at the RPC, but this commit fixes it.
Before this commit, it was not possible to add an amount to a new
bank statement. The input (.o_form_field_monetary) appeared as disabled.
This bug was due to this commit: @a1224f5ca
This rule should be only applied to .o_form_field_radio.
Closes#18887
Task ID: 35832
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
1. `background layout` report template should keep the min-height property to
avoid breaking the pdf report template.
This property is needed to display the background image at the right position
(avoid image to be crop if not a lot of invoice lines). see https://github.com/odoo/odoo/commit/41c75ad0c37d567dd43e418fda927c7ae38a3add
2. margin-top can't be applied or it will also break the pdf layout.
`min-height` will ensure that the html rendered will be high enough to looks
like the real pdf invoice anyway.
opw-39876
*account_payment, l10_in(_sale), sale(_stock), web
With this commit:
The invoice preview in portal (/my/invoices..) is now the HTML version of the
PDF report.
The HTML preview is based on the invoice report to closely match what is
already done in Odoo.
The invoice preview is displayed in an 'iframe', it is mandatory since:
1. Reports are rendered as a separate page as it returns the whole page after
rendering, which has tag <html>, <head> etc
2. Reports are having their own layouts and their own assets that we we cannot
load in the page directly or it will break the website layout.
3. We can not use report template with t-call because internally reports are
using extra params like context_timestamp, company, DateTime, user etc which
is used in header/footer
--
There will be a chatter (as a modal) to display/see the history of the document
--
For responsive purpose, we use new tables with limited column (Description,
Quantity and Amount) for responsive purpose (small screen).
It also adds some bootstrap classes to reports for responsive purpose.
--
The 'Pay Now' button remains if you already paid with 'wire transfer'.
--
Add margin after the header and before the footer to look like the real printed
document, without alterating the real printed version
Task ID: 39876
*: hr_gamification, point_of_sale, web
Before this commit, no content helper in some form view fields were broken,
due to the style of the classname `.o_view_nocontent` that uses an absolute
position.
This is due to some templates that wrongly use this style for displaying a
help message, although this is only valid for views with no record.
This commit solves the issue by using another classname for those fields
with the nocontent helper, namely `.o_field_nocontent`.
Before this commit, the point of sale displayed a loading message
every 5 secondes if the barcode scanner was configured.
This issue is due to the following commit: @1aacc96
After this commit,some calls may block the interface when they did
not do it before.
It concerns all rpc done with ajax.rpc and all done with a new
session.
We have now to explicitly set shadow property.
opw-1860493
Let's assume a one2many A inside a form view, such that the one2many
views (list, not editable, and form) are defined inline, and there is an
onchange on A. There is another inline one2many B editable list
displayed in the inner form view (and B isn't in the list). There are
two records on the one2many A, both of them having one record in their
one2many B. Edit the first record of A, and edit it's subrecord in B.
Click on save. This triggers an onchange on A and the onchange returns a
command 5 (DELETE_ALL), and two commands 1 (UPDATE). Now edit the second
record of A, and simply close the dialog (e.g. 'Discard'). Save the main
record: the record in one2many B of the second record of A has been duplicated.
This occured because the code in BasicModel messed up information coming
from the onchange (UPDATE command) and from the read (performed when
opening the second record), thus producing a CREATE command instead of
an UPDATE one.
This rev. ensures to properly mix the read data with the onchange
result, by transfering the changes over the list datapoint created after
the read.
opw-1836785
closes#25330
Let's assume a one2many list with two fields A and B, and an
onchange on A that sets B. Before this rev., on new records, the
onchange was only triggered if the one2many list was defined
inline.
Rev. 13c885195 was an attempt to fix the onchange issue in x2manys
with non inline views, but it only worked on existing records. This
rev. fixes the problem for both cases (existing and new records),
and thus reverts the fix of 13c885195.
The idea of this fix is to make both cases behave similarly, w.r.t.
fields and viewFields stuff in the fieldsView. In the inline case
(like in the main view case), fields and viewFields are the same.
In the non inline case, viewFields contained more information than
fields. As fields is used everywhere in BasicModel (and viewFields
is basically ignored), the fix is to set fields to viewFields.
Let's assume a one2many list with two fields A and B, and an
onchange on A that sets B. Before this rev., on new records, the
onchange was only triggered if the one2many list was defined
inline.
Rev. 13c885195 was an attempt to fix the onchange issue in x2manys
with non inline views, but it only worked on existing records. This
rev. fixes the problem for both cases (existing and new records),
and thus reverts the fix of 13c885195.
The idea of this fix is to make both cases behave similarly, w.r.t.
fields and viewFields stuff in the fieldsView. In the inline case
(like in the main view case), fields and viewFields are the same.
In the non inline case, viewFields contained more information than
fields. As fields is used everywhere in BasicModel (and viewFields
is basically ignored), the fix is to set fields to viewFields.
RomainLibert