| Age | Commit message (Collapse) | Author |
|---|
|
Form sheet with hidden overflow (added to improve ribbon widget css) prevents
emoji button from showing emoji list when clicked. This commit attempts to
show the complete emoji dropdown by removing overflow from the sheet container.
IMPORTANT : This override won't affect ribbon since the hidden overflow was
added on the widget itself.
Task ID-2224393
PR #49096
|
|
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closes odoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
|
|
We added min-height for `o_form_sheet` in form view with a commit[1] restoring
the views design (after views refactoring).
However, the min-height isn't very useful when form view is opened witin a
modal (FormViewDialog). Especially, when the form view is having only few
fields, the `o_form_sheet` container occupies unnecessary height and looks
a bit ugly.
This commit fixes the issues by setting the min-height to `0` for
`o_form_sheet` container in such cases.
[1] - https://github.com/odoo/odoo/commit/250e716c3a12#diff-01e46b3171a7282967199e5d45fca0e6R15
TaskID: 2150471
PR #41619
closes odoo/odoo#43865
X-original-commit: 144d720bdc54ce762b84b1a78aa7e517ec1c3dd2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closes odoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
The planet icon is not very clear for translation feature.
Replace it with the code of the current language.
Task-id: 2028152
|
|
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
A POC for a new ribbon widget has been recently introduced at 02fbb737b96ab8e35123219db5cdcc008729953b.
It adds a ribbon on the top right of a form to make some status more visible
and more user friendly. This commit greatly improves the design of this
ribbon in order to have a real ribbon.
You have to specify the text attribute to show the text on the ribbon.
You can also specify a bg_color attribute to color the background with a
bootstrap background color class according to the business meaning of the
flag displayed in the ribbon.
LINKS
Task ID : 2032621
PR : #34662
|
|
closes odoo/odoo#35404
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
In order to display properly the futur ribbon, community stat buttons to
be displayed like in enterprise
task-2035081
closes odoo/odoo#35040
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
|
|
Commit https://github.com/odoo/odoo/commit/8caf84f70ada259f041b424d37686845604d182a
was not handling the case where there was an invisible DOM element
between the button box and the alert component. Let us clear all alerts.
This commit also introduces a way to properly fix/extend bootstrap in
future fixes/updates (some of our rules may already be moved in that
file once it is forward-ported to master).
closes odoo/odoo#27662
|
|
On the user form view, just after the button box, there might be an
alert component. Since BS4, this alert goes over the floating button
box in community. Before BS4, the button box went over the alert (so it
was functional but still ugly).
This commit adds an extra style for community only: clear the button
box before an alert component.
Closes https://github.com/odoo/odoo/issues/27435
closes odoo/odoo#27566
|
|
Task-ID 1878649
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
This is a simple renaming without adaptation.
|
