When rating with the smiley mecanism, the rating value will be 1,
3 or 7. The rating model allow value in range [0, 10]. When using
the star mecanism, usually, only 5 stars are used to introduced a
rating. This will set a rating value in the range [0, 5], which
is not aligned with the range of the model, nor the smiley range.
Purpose of this commit is to uniformize the range of rating, so if a
model is using both mecanism, the average will be correct. Solving
this problem implies to apply a conversion factor between the
database value and the displayed one.
Migration:
As only product.template was using star mecanism in odoo community,
a migration step should be applied to multiply of ratings of
product.template by 2.
Task-1941432
closesodoo/odoo#31141
When website_rating is installed, all frontend chatter will have
the string 'false' by default in the composer. This commit fixes
that, restoring the placeholder
closesodoo/odoo#31097
When a portal user post a message to review a channel, we
want to allow him to edit its own comment and rating.
This commit modifies the special check access method in
portal to extract the security check and reuse it to
allow user to update its comment on slide.channel only.
We decided to reuse existing widget (new rating popup
composer) to do the message modification.
Task-1902304
This commit fix the display of a label when the user add
a review; when selecting desired stars, the label corresponding
to the star is displayed in a badge.
The bug probably comes from the update to bootstrap 4.
Rating document available on a website will become more common, but
we want to do it with different UI widget. This commit introduces a
new "popup rating composer": the idea is the rating average is
displayed with stars, and when clicking on it, a popup with the
composer appears. The user can so submit its review.
To do so, we factorize the Portal Composer into a dedicated widget
(instead of natively inside Portal Chatter).
Task-1902304
This commit provides 1 more field on the rating mixin: the average of
the ratings of the document. Before that, the only way to get the
average was to call `rating_get_stats` record per record.
As we are on a mixin, this new field is not stored to avoid recomputation
each time a rating is added. To improve performance, we decided to
compute `rating_count` and `rating_avg` in one `read_group`.
This commit also set an extendable method to get the domain of the
rating to include in those statistics computation, called `_rating_domain`.
This way, each model inheriting the rating.mixin can define the subset of
pertinent ratings.
As consequence, this commit uniformized the way average is displayed:
instead of taking the closer value to the 0.5 value, it only round it
at 2 digits.
Task-1902304
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.
BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.
The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:
$gray-darker -> gray 900 (unused before)
$gray-dark -> gray 900
$gray -> gray 700
$gray-light -> gray 600
$gray-lighter-darker -> gray 400 (the old variable was created by us)
$gray-lighter-dark -> gray 300 (the old variable was created by us)
$gray-lighter -> gray 200
Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.
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
Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
jem-odoo