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
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.
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
In this commit, we extend the search view to allow the selection
of some intervals for date or datetime fields in groupby menu.
The valid intervals are day, week, month, quarter, and year.
It is also possible to add a button 'Group By' in the control panel
owned by a graph view in case it is declared 'embedded' (e.g. in a
dashboard view).
Note that have three new generic reusable widgets have been introduced
in this commit: DropdownMenu, GroupByMenu, and FiltersMenu.
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes#24988
This commit introduces a new widget to be used for selection-based fields.
Valid choices are displayed using rectangular badges and not like the
standard list. This widget is valid for selection and many2one fields
like selection or radio widgets.
Co-authored-by: Siddarth Gajjar <sga@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this rev. the `column_invisible` and `default_order` attribute, set in a
x2m list view were only taken into account for inline views.
The technical reason behind is because non inline views are fetched after the
main view processing.
Non inline x2m list views now correctly handle these two attributes.
Model A has a o2m to model B
Model B has a m2o parent_id on B
In A's form, add a B item,
then in the m2o, create record
Save and New
Click on the m2o
Before this commit, the python crashed on name_search.
This was because we sent the virtual ids to it
After this commit, there is no crash
OPW 1850212
closes#24948
Have a decorated (conditional on field) editable list, with a default_order.
Have more records than the pager allows.
Add an item, and hit escape to cancel addition.
Before this commit, the cancellation crashed because the first record on the other page
was trying to evaluate the decoration for its row, which is wrong in the first place.
This was because creating a record increases the limit of the list, to be able to see the record
being created.
At cancellation though, that limit was never decreased.
After this commit, the whole flow happens without problem.
OPW 1844495
closes#24682
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
Before this commit, some records in a list did not show the name of their
many2one fields.
This case occurs when the records in the list are created from a default_get,
and the records do not fit in a single page. In that case, the records in the
first page correctly display the names of their many2one fields, but not the
records in the other pages.
Fixes#24547
Before this commit, when a list contains records with many2one fields that
contain the same values, duplicate ids were passed to the server on rpc
`name_get`.
For instance, if 40 records in a list refer to a Unit of Measure with id "1"
whose displayed_name is "unit(s)", the server receives a long list of ids with
simply the value "1". Also, the server responds with a list of displayed_name,
in this case a list of 40 strings "unit(s)".
With this commit, we always pass unique ids to the server on rpc `name_get`.
When sorting records according to a many2one field in a list view
embedded in a form view, the js would sort according to their ids,
in a seemingly arbitrary order.
Thus sorting records according to a field with values in ("a", "b", "c")
could be sorted as "a", "a", "c", "b" instead of "a", "a", "b", "c".
We make the comparison on the name of the field instead.
opw 1838860
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
Have a One2Many
The views of that o2m define two inline views: the list and the form
in the list view, put a field that isn't in the form and used in a domain
Try to add an item to the list
The form pops up
Fill in the data and save & close
Before this commit:
It crashed when evaluating the domain on a field using the field that is not in the form
After this commit:
Subviews share their fields in a special object on the parent record
In our case, the form view checks in that shared resource if the fields it is supposed to initialize
are there.
Hence, this flow doesn't crash anymore
OPW 1837511
closes#24350
... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
Christophe Simonis