| Age | Commit message (Collapse) | Author |
|---|
|
odoo/odoo#4c291e3f7049c3af859902a6f5857eab68be2f9e changed theme
categories from Theme to Website/Theme, however theme support has
technical dependencies on the category, so this breaks
design-theme (which was missed as design-themes was not yet under the
Not Rocket Science Rule).
Revert the change specifically for the theme modules.
closes odoo/odoo#47059
|
|
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closes odoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#40517
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Commit https://github.com/odoo/odoo/commit/88e910e187346c095a6f0eeb8be647da1e391035
merged the inheritance of a view into the base view while the inherit
was in fact a primary mode inherit. The modal buttons of website
creation modal thus appeared in all website forms by mistake.
This commit also takes advantage of the fix to fix the design of that
creation modal (wrong classes on buttons).
Also fixes https://github.com/odoo/odoo/commit/986415cf050efbd38a5834f9bbd3a37db1fd7933
which added a data file & folder in demo data by mistake.
closes odoo/odoo#40175
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
The original goal was to not have any pre-installed theme by default
and to force the user to consider installing one through the customize
dialog.
Now that we have a system to allow switching theme, it is better to have
one installed by default and allow the user to switch theme from the
customize dialog (note that last part was made in the parent commit with
the merge of website_theme_install into website).
Note: theme_default is purely empty, it is only installed by default for
clarity in the theme selection screen, for the default website.
|
|
* theme_bootswatch, theme_default, website_theme_install
|
|
*: theme_bootswatch, theme_default
Before this commit, the first time a website was loading a theme, it would
not be redirected to the frontend afterward (even if that theme was already
installed on another website).
Any other theme installation on that website would redirect to frontend as it
should.
Indeed, the first time it would use the `act_url` returned by `next()` which
would only be called during the first time installation on the website.
All the `ir.action.todo` related to themes can be removed anyway, as you can't
install directly a theme. It can only be installed through website settings >
load a theme.
In which case we will always want to redirect to frontend.
task-2070463
closes odoo/odoo#37306
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
closes odoo/odoo#35754
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
|
|
* theme_bootswatch, theme_default, website_theme_install
This commit makes use of the new 'auto' widget for font selection:
instead of enabling a template which will enable a scss file which sets
a font variable to a specific value... we directly allow to do a scss
custo which sets that value.
The code in charge of resetting font customizations on theme switching
is also moved and refactored here in website (instead of being specific
to each theme).
Part of https://github.com/odoo/odoo/pull/33442
task-1974659
Co-authored-by: qsm-odoo <qsm@odoo.com>
|
|
* theme_bootswatch, theme_default
Allow to disable/enable a view from a xml_id whether the xml_id is
linked to an ir.ui.view or a theme.ir.ui.view.
|
|
* theme_bootswatch, theme_default
Before this commit, the customization dialog for themes was not
multi-website. That means if a theme was installed on a website, the
customization dialog was enabled for all the websites.
Note: this commit uses the '_post_copy' system of theme installations
for the first time and it had to be adapted a little bit.
|
|
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
|
|
The theme will be reviewed and merged with website app.
|
|
|
|
|
|
|
|
|
|
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.
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
media queries that target a specific screen size handled by bootstrap
have now a more convenient way to be defined:
```
@media (min-width: $screen-sm-min) { ... }
->
@include media-breakpoint-up(sm) { ... }
```
```
@media (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-down(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-only(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-md-max) { ... }
->
@include media-breakpoint-between(sm, md) { ... }
```
Also, bootstrap has changed the values for its default screen sizes:
------------------
| BS3 | BS4 |
------------------
0 | XS | XS | -> Portrait Mobile
576 | / | SM | -> Landscape Mobile
768 | SM | MD | -> Portrait Tablet
992 | MD | LG | -> Landscape Tablet / Small Desktop
1200 | LG | XL | -> Desktop
------------------
While it is possible to configure BS variables to behave as BS3, we took
the decision to keep the BS4 variables untouched. BS4 system seems
indeed better and having the purest bootstrap possible is better for
Odoo to be used as a framework.
|
|
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
|
|
|
|
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
|
|
This is a simple renaming without adaptation.
|
|
|
|
|
|
|
|
task-32528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a theme is customized to be 'boxed', the website is not full width
in mobile, and there is an horizontal scrolling.
To fix this issue, we removed only set the width of the "wrapwrap" div
to 85% when the screen is bigger than a phone.
|
|
|
|
|
|
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes #14937
|
|
|
|
- Previous information:
- `es_MX` language is not published to [transifex](https://www.transifex.com/odoo/odoo-10/languages/) this is a official announce from thread [Regional languages and Spanish (Latin America) translations](https://www.odoo.com/es_ES/groups/community-translators-63/community-translators-20325962?mode=thread&date_begin=&date_end=) by @mart-e
- Currently we have the files `es_MX.po` with terms translations outdated or wrong translation.
- [Example wrong translation es_MX.po](https://github.com/odoo/odoo/blob/8de795291/addons/account/i18n/es_MX.po#L7788) should be [es.po correct translation](https://github.com/odoo/odoo/blob/8de795291/addons/account/i18n/es.po#L7975)
- Now to change a `es_MX.po` a PR is required.
- `es.po` terms translations and the most terms are fine for México too. (Not regional translation is required for most cases)
Then our regional translation process should be:
| step | If accepted | If not accepted |
|------|-----|-------|
| Create a proposal to original language `es.po` from transifex | good and finish! | Create a new PR to odoo/odoo adding just that special term to `es_MX.PO` |
This PR reset the `es_MX.po` terms in order to fix many wrong terms using the good `es.po`.
Closes #14555
|
|
|
