* web_editor, website_slides
Current system is styling all navbars with the user color. This was not
the expected behavior but it is in fact quite nice, so we decided to
keep it. There was however a problem: choosing the menu text color only
applied to the main navbar (as it was an xpath toggling the navbar-dark
class).
This commit solves the problem by forcing navbar-light to behave as
navbar-dark automatically if the menu background is dark, and this
without any JS or extra CSS rules. This allows to get rid of the menu
text color option.
This commit also reviews the light and dark colors which are used when
website is not installed.
As an `form-group` can contains element having `form-control` class and other
not having it, we should not force height on `form-group` elements.
Typically, we could have:
div.form-group
input.form-control
button
Forcing height only on `form-control` will make the input thinner than the
button.
The menu item dialog is an extension of the link dialog where all the
.form-group elements which contain a .link-style option element are
removed. A new link style option was recently added but with the wrong
class, preventing it to be removed for the menu item dialog.
task-1878245
By default, all btn colors are suggested in the link dialog (alpha,
beta, gamma, delta, epsilon, link, primary, secondary, success, info,
warning and danger). In lots of themes (and the default one), primary
= alpha and secondary = beta, which led to having two suggestion with
the same apparent color.
A new system was introduced to automatically remove the duplicates...
but this system also removed the button preview as it considered it to
be a duplicate.
This commit also adapts the preview to BS4.
task-1878245
Commit https://github.com/odoo/odoo/commit/903ff171acbef7f9fe6e533f43b99eba801b200f
lowered the font-size to 14px for the frontend by customizing the
bootstrap variable in the portal app. It changed the web_editor
rte_inline tour accordingly.
This however broke the test on runbot "base" database, as the font-size
in the editor without having installed the portal app was still set to
16px. Commit https://github.com/odoo/odoo/commit/e3bc059c3649a05c12cd3c8099092282c10141b7
only moved the failed test from "base" to "all" database.
This commit unifies the font-size for all frontends by setting it in the
web app. So, after this commit: reports, editor, login screen and
frontend will always have a font-size of 14px no matter the application
which is installed (except themes).
With BS4, the website's font size was set to 16px instead of 14px as
before. We finally decided to force the 14px back. This commit also
moves some bootstrap variables extensions to portal as it should have
been done and reformat the files to match the bootstrap _variables.scss
file.
* website
```
$map: (
test: 1,
black: 2,
);
@debug map-get($map, 'test');
@debug map-get($map, test);
@debug map-get($map, 'black');
@debug map-get($map, black);
```
The above code leads to a:
1
1
null
2
This is because maps' keys can be *anything* in sass (even other maps).
In the example, the map is defined with unquoted `test` and `black` as
keys which are understood as the string 'test' and the *color* black.
When asking for the value for the 'black' string key... there isn't any.
This commit forces the use of quoted string as color maps' keys.
Make some changes which are needed for theme migration.
- Theme colors as user colors fallback only (not hard choice)
- Review option dependency system
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes#26366
opw-1874880
closes#26582
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
[FIX] web_editor: adapt col size to avoid too small select
We should avoid col-md-3 in col-md-9 as the menu dialog is instanciated at 2
places:
- When creating a link in the editor
- When editing website navbar menu
In the second case, there is a hack in `content.js` to remove `modal-lg`
lowering the width of the modal and making the select too small.
[FIX] website: lower navbar font size
With BS4, font-size of navbar element went from 13px to ~17px (rem unit
computation).
14px seems better than previous 13px as the frontend content size is
higher than the backend one. Thus, 13px looks too small in contrast with the
frontend page content.
[FIX] website_crm_partner_assign, website_customer, website_membership: fix layout
This commit fixes multiple layout issues, mainly by aligning code of the 3
modules:
- Add margin right to avoid text to be against image
- Using image_medium everywhere
- Fixing search input width
publish toggle red + odoo primary is weird -> gray
navbar now has a background & float-right not working since flex
-> remove navbar class, use d-flex and ml-auto so the right element will be floating since using all available width
task-1878150
* web, website
- Introduce gray color palettes (needed for themes migration)
- Synchronize BS4 color maps with individual variables (see comments
about this in the code).
- Review alpha/primary, beta/secondary matching:
Before this commit, we decided that the common way to define a color
palette was defining primary, secondary, gamma, delta and epsilon.
alpha and beta were then forced to primary and secondary without other
possibility.
The new system makes more sense:
1) define alpha, beta, gamma, delta and epsilon
2) primary and secondary will automatically be set to your alpha and
beta (allowing to style the default UI with BS4-independant
variables)
3) if you are not happy with (2), you can define primary / secondary
in your color palette so that they are not automatically set to
alpha / beta
This commit also changes what classes the editor uses. Background colors
and text colors will now use alpha/beta/gamma/delta/epsilon (not primary
and secondary anymore). For buttons, all the possibilities are suggested
but color duplicates are hidden (so if your primary and alpha are equal,
only one button color is suggested).
Sometimes, two dropzones end up at the exact same location (if two
oe_structure are somewhat siblings for example). Before this commit, in
this context, if the user hovered that location with a snippet, then stopped
hovering that location, here is what occured:
- the snippet preview is dropped after the zone 1 and the zone 1 is hidden
- the snippet preview is dropped after the zone 2 and the zone 2 is hidden
- the snippet preview is removed and the zone 2 is shown again
- ... the zone 1 is forever hidden
After this commit, the snippet preview can only be dropped once.
Dropzones between columns were displayed vertically, they were detected
thanks to their 'float' property. With BS4, columns are not floating
elements anymore, they use flex. So the code had to be adapted.
- The current code found colors in the page which were not custom colors
(because we were case-sensitive for hex values)
- Applying custom colors font font/background were inverted
* web_editor, portal
This commit introduces the first page options: header overlay and color.
The website builder is improved to allow the management of those. With
this commit, users can now click on the website header to make it go on
top of the first snippet, with a chosen transparent color. This is a
configuration that can be done on each page individually (as the feature
is very dependent of the first snippet on the page, this is typically an
option for homepages).
task-32155
* web, web_editor, website_hr_recruitment, website_mail_channel,
website_mass_mailing
- Review all snippets and add new ones
- Add lots of new options
- Use odoo colors as default theme colors
task-38878
- Custom color can now be applied to elements
- Find used custom colors in the page and add them as colorpicker
suggestions
- Current color is selected in the picker when you open the custom
color wizard
task-37974
Closes#26274
- Split editor button: one for font color and one for background color
- Remove recent color button feature
- Add only theme colors and remove other color sections like
graypalette/standard colors
- Button's icon for font color and background color buttons have the
same color of currently selected element
task-37974
Closes#26274
* 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
If a user embeds a youtube video on his website, he has no option to remove the
suggestion of related videos at the end of playback.
Since there is no good reason to have it, we disable the related videos in all
cases.
opw 1868380
The purpose of this change is to make the code clearer and testable.
In this change, the 'tab_manager' static object was merged with the bus
cross tab.
Cleaning was done to clearly define private and public functions as well
as handlers. The methods are documented and the constants are now defined
on the class. The bus use the service behavior with 'trigger_up'.
'bus.CrossTab' who extend 'bus.Longpolling' are instantiated by the
bus service.
The class is always instantiated with a parent, or root in the case of the website
(im_livechat), to use the ajax and localstorage services. So the behavior, perhaps
logger or redefined by the parents.