Before this commit : The library underscore.js and
underscore.string.js were used in the ODOO solution.
After this commit : Every usages of a function from
underscore.js lib has been replaced with native javascript.
The goal is to remove all usages of underscore.js and to
not use anymore this library in ODOO.
---
TaskId : 3246238
closesodoo/odoo#120437
Signed-off-by: Géry Debongnie <ged@odoo.com>
hr_recruitment: switch smart button value and label
- Switching applicant's name with "Employee" label to be consistent with
the rest of smart button's format
mass_mailing: adapt status bar layout
- Removed excessive margin between the status bar and the content
- Added no padding between status bar and the control panel
- Removed a useless border before the status
- Improved margin between alert and buttons
project: right side panel stats buttons alignment
hr_skills: fix `::before` alignment
== ISSUE ==
Before this commit, the :before line in Employee resume is not aligned
with the dots. This is due to the fact that the variable
$o-hrs-timeline-entry-padding used in the mixin isn't the right value we
should use.
There was also an issue with responsive.
== After this commit ==
We now use a calc, which process the half of the circle plus the padding
minus the border-width. The $o-horizontal-padding is the variable used
to define the padding of the line inside the form view.
We adapt this in a smaller media query since the $o-horizontal-padding
value is different.
task-2818586
Part-of: odoo/odoo#116641
Commit [1] defined a value for the `onWysiwygBlur` option of `Wysiwyg`
in the `mass_mailing` `html field`. This had the side effect of
overriding the value set by its parent `html field`, which was to call
`commitChanges`. As a result, the `mass_mailing` `html field` was not
saving its content on blur. This restores that behavior by explicitly
adding the call to `commitChanges` where it was missing.
[1]: https://github.com/odoo/odoo/commit/e212e873eb35eb9b9a931fb1521109475c008074
task-3288881
closesodoo/odoo#121231
X-original-commit: 817d494e4eaa29983f75d4f3d6754ef3c3cc6e51
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Prior to this commit:
When the mobile preview is clicked in the mailing template of the marketing
automation, the preview is empty. The preview is seen after closing all the
dialog boxes, but it is still not obtained as expected.
Post this commit:
The mobile preview is working properly while clicking on the preview button.
Task-3272504
closesodoo/odoo#120415
X-original-commit: 095b456bf518a6730b5b0039fef40f4cfe8e3511
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a basic tour for creating a mailing from a campaign's
"Mailing" tab, via the list view of the `mailing_mail_ids` one2Many field.
closesodoo/odoo#119918
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The campaign's "Mailing" page displays the one2Many `mailing_mail_ids` field
in a list view. When creating a new mailing from this view, a new record is
created with the fields from the comodel(`mailing.mailing`)'s form view, which
does not have the necessary "body_html" field.
This resulted in a traceback when attempting to save changes to the newly
created record, as `MassMailingHtmlField.commitChanges` calls `Record.update`
for such field.
This commit ensures the `body_html` field is present by adding it as a
dependency of MassMailingHtmlField.
Task-3225211
OPW-3204686
Part-of: odoo/odoo#119918
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
*: mail, mass_mailing, sms, web_editor
This commit adds a new supportedOptions attribute that can be added to any
field widget metadata object. This documentation can be used from other places
(Studio for example) by getting the field from the registry and then read
this key. This attribute can contain an array, detailing the list of available
options for the field widget.
By using an array, it can be ordered easily without having an object with keys
unalphabetically. Ordering the options can make sense, especially when two
options are tied to each other, it is easier to group them one after the other.
(eg: 'start_date' first, then 'end_date')
Each option documented is an object and has the following attributes:
- help: contains more details on the current option and its use
- name: name used in the options object from the node
- label: a label with a more explicit name than the option name
- type: the type of value that must be used as a value (string, boolean, selection, field, domain)
- choices: for options with a 'selection': can be used to know available values
where multiple values can be chosen as the value. This must be
an array containing the options.
- availableTypes: for options with a 'field' selection: can be used to filter the
available fieldNames to choose as a value.
- default: the value that is used by default, when the option is not set
in the options
task-3259617
closesodoo/odoo#118713
Related: odoo/enterprise#39847
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit:
In email marketing, when we click on the import button of the "mailing list
contacts", we find a needlessly large gap beneath the contact list.
Post this commit:
The class which creates the space is removed and hence we get the required output.
Task-3258581
closesodoo/odoo#119884
X-original-commit: 1ee98fb9f6bd8289c5ffcada14c3db62afba5a0d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the module "web.dom_ready" and
adapts the modules that imported it.
This module was used to wait for the content to be
loaded to manipulate the dom after that.
The goal is to remove async modules and simplify the
module loader in the future.
task id: 3265979
closesodoo/odoo#119158
Related: odoo/enterprise#40051
Signed-off-by: Géry Debongnie <ged@odoo.com>
Replaced _.each() functions (average 235 occurences)
Description of the refactoring this PR addresses:
Current behavior before PR:
There are underscore.js function enumerated above used in odoo.
Desired behavior after PR is merged:
These functions has been replaced by native javascript
prototypes/methods/functions.
TaskId : 3246238
closesodoo/odoo#118565
Signed-off-by: Georis François (fge) <fge@odoo.com>
Steps to reproduce
==================
This only seem to happen on Firefox
- Go to Email Marketing
- Open a campaign
- Go back to the homepage by using the topleft square button
-> `$(...).offset() is undefined`
Cause of the issue
==================
The ResizeObserver used in MassMailingFullWidthViewController is still
triggered, even though it shoudln't.
Solution
========
Disconnect the observer when the component is unmounted.
opw-3271101
closesodoo/odoo#118785
X-original-commit: d5f6bc2b33c3b83520ed2ed710610b69dbe67b75
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
A mailing based on the "basic" theme is a particular case where there is
no SnippetsMenu and the floating toolbar is present instead. This commit
includes a tour for this previously untested case/flow.
Part-of: odoo/odoo#117166
Short read version:
This commit gives the Wysiwyg class the attribution of switching between
the two types of text editor toolbar (floating or part of the sidebar),
instead of the SnippetsMenu class, as Wysiwyg owns the Toolbar instance
and has the methods to configure it.
The switching between toolbars is now done by having one instance of each
type (and properly displaying/hiding them), rather than moving the toolbar
element of place in the DOM and reconfiguring it (button handlers, CSS
classes, displayed/hidded buttons, etc), so that the configuration steps
of each toolbar can be done only once.
The floating toolbar is needed for mailings based on the "basic" theme,
where no sidebar/SnippetsMenu is available. Note that it will be only
instantiated if needed.
Long read version:
The 'basic' theme in mass_mailing has no sidebar (SnippetsMenu), so the
floating toolbar should be available instead, in order to give users access
to the text editor's features.
Commit [1] added the `setFolded` method to the SnippetsMenu class, which folds
(hides) the snippets menu and recovers the floating toolbar from the
sidebar container and vice-versa. While the recovered toolbar works well when
`isMobile` is `true` (although with some minor issues described
below), the one for the non-mobile case does not (as it must be properly
reconfigured using the document's Jquery, and not the iframe's, among other
details).
This commit proposes a different approach to the toolbar recovery issue:
if the floating toolbar is needed (mobile or basic theme), a new Toolbar
instance is instantiated and properly configured. That way the Wysiwyg
instance will hold two instances of the toolbar: the one embedded in the
sidebar (snippets menu) and the floating one. This allows for easy
switching between the two types of toolbar, without the need to run the
configuration steps for the toolbar on every switch.
Such toolbar switching is needed in mass_mailing, where a single instance of
the wysiwyg is kept while the user can switch between different records of
mailings. Some of these records could be based on the 'basic' theme
(thus, no sidebar), and other ones based on other themes that do offer
the snippets menu.
After this commit, the toolbar switching is handled by the Wysiwyg class
instead of SnippetsMenu, as Wysiwyg owns the Toolbar instance(s) and has
the methods to configure it.
The `folded` property of SnippetsMenu and the `setFolded` method are
leveraged by this commit, keeping its original purpose and meaning (except
for the toolbar handling).
Before this commit the floating toolbar for the mobile case had the
following issues, that are fixed by this commit:
- The "table" button was (incorrectly) displayed;
- The default colors of the color picker (the top row) were undefined;
- The 'Link' powerbox command and the toolbar icon should open the Dialog,
and not the LinkTools (part of the sidebar).
Finally, this commit removes the SCSS rules that hide the SnippetsMenu
when the theme in "basic", as its display is already handled by
SnippetsMenu's `setFolded` method, introduced by [1].
[1] https://github.com/odoo/odoo/pull/105472/commits/c589939eeaff928997bf6f9735b19710036f9ad6
task-3133259
opw-3165111
Part-of: odoo/odoo#117166
Steps to reproduce bug:
Loop through the form view of mailing records having at least one of
them the 'basic' theme, and the other ones any other theme.
Once a mailing has the 'basic' theme, the sidebar is hidden (expected
behaviour). But the sidebar will remain hidden for all mailing records,
even the ones based on different themes (that would normally display the
sidebar).
The cause:
There's a CSS rule to make 'display: none' when the iframe's body
has the 'o_basic_theme' class.
(see addons/mass_mailing/static/src/scss/mass_mailing.ui.scss)
And the theme class is not properly cleared when switching between records
of different themes.
This commit fixes the issue by properly removing any theme classes
before adding the current theme's one.
Part-of: odoo/odoo#117166
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce:
- Get Marketing Automation module and mass_mailing module
- Go to Marketing Automation > Configuration > Favorite filters
- Create a new filter with for example, Recipient Model as Contact and
the domain to be 'Name contains test'
- Now we go back to Campaigns (Inside Marketing Automation) and create a
new campaign with the filter that we have just created.
- Create a new activity for this campaign with any mail template and
save it.
- Now just pres "start" to start the campaign.
- After that you can also use "Launch a test" to see the trace-back.
Issue:
We receive a trace-back when we try to access to a value of a undefined
object. That it is launch whenever we have a campaign with filters.
Solution:
Added the handling of the case when the inputElement is undefined.
opw-3146908
closesodoo/odoo#117185
X-original-commit: b5b0d665ef2ea492bf7f9823da7f7982b0ddefa6
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when toggling the codeview in mass_mailing (debug=1),
the overlay that highlights the selected snippet is not deactivated.
This results on the blue rectangle being seen on the codeview when the mouse
cursor is hovered over the corresponding position.
This commit deactivates the current snippet overlay when the codeview is
toggled.
closesodoo/odoo#115299
X-original-commit: ec8070adb38d092d743679c2dd30872424d46e9d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Since [1], some mass_mailing snippet templates now have images with
shapes by default. However, the shapes were not added correctly:
- for the Blockquote snippet, the files specified are not correct (wrong
names and wrong extensions).
- for the Team snippet, the shapes are not present when dropping it.
This commit fixes that by properly adding the shape images as defined in
the commit [2]. It also removes the "circle images" files as they are
not necessary anymore. The basic shapes were also fixed by removing
their width and height, since the dropped snippets looked weird because
their images have a default width smaller than the shapes.
[1]: https://github.com/odoo/odoo/commit/f4995f560003c2180ad3cef50e1b172a151e50c8
[2]: https://github.com/odoo/odoo/commit/eb1262960f54fd81424a86ef4d6693a950e76cb4
opw-3137732
closesodoo/odoo#114966
X-original-commit: b1a3a3b18370ad76280726298602815769dce1c2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Commit [1] cloned the contents of the edited e-mail to a temporary
iframe before inlining its HTML (`convert_inline`). However, the assets
were not properly loaded in the iframe, which prevented the inliner from
doing its job properly, in particular with fonts (e.g., Font Awesome
icons were not loaded so they couldn't be converted to images).
This uses the `srcdoc` attribute of the iframe instead of replacing its
HTML element with a clone of the edited e-mail's, making sure to remove
all scripts from the iframe to prevent them from running, and disabling
script execution in it as a safeguard.
Steps to reproduce an example bug fixed by this commit:
1. Start a new e-mail with the "empty" template
2. Add a "Left Logo" snippet
3. Save
-> The Font Awesome icons are missing from the saved e-mail, the font of
the text is wrong, and the image is stretched out.
[1]: https://github.com/odoo/odoo/commit/582567fa13cef3e5fee00a17ff52c623ba5422f2closesodoo/odoo#113687
X-original-commit: 79dc6384329b1e8bd2338160d62028ac0c1cdce4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit fixes the issues in the mass_mailing module where the display
needs to be grid, and the dropdown dynamic is causing issues because of
the css rules transform and unset.
Popper.js manipulates transform and the position of the dropdown, and
in mass_mailing, its calculations are wrong.
These !important rules stops it from doing so, by unsetting the automatic
rules generated by Popper.
Part-of: odoo/odoo#110161
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Before this commit
Many of the usages of the "throttleForAnimation" util did not
cancel the call to the throttled function when the using
component is unmounted.
After this commit
A "useThrottleForAnimation" hook:
- is introduced
- is tested (as of the prior "useDebounced" hook which was not)
- replace the "throttleForAnimation" usages.
closesodoo/odoo#112913
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, `commitChanges` was inlining even when the content
did not change. For instance, this event was called on every change of
the record through the "next record" button of the form view.
As toInline is computationally expensive, this commit execute it only
when necessary (i.e. when the content is dirty).
When there is a save action that is triggered in mass mailing (eg.
through the button, breadcrumb, urgent save), if a previous call to
`commitChanges` is still in progress, the inline field migth not be
saved, thus we need to wait for a pending promise.
task-3052658
X-original-commit: 3d43d462758c3c9b3817a7c19ccd88517f8625e1
Part-of: odoo/odoo#112908
Before this commit, openning a mass mailing tried to load an image
that was not present in the module, where the server took some
seconds to respond, slowing down the openning of the mailings.
task-3052658
X-original-commit: d80ed2814730f0074f2c5acf56ca385f6b9513e6
Part-of: odoo/odoo#112908
Before this commit, some operation (eg. move node, duplicate or remove a
snippet from the snippetMenu) in the snippetMenu sidebar did not
trigger the mass mailing commit changes and therefore if no selection
was made in the document followed by a blur was made, no changes could
be recorded and saved by the owl form component.
task-3052658
X-original-commit: 8bd8db97ee0d7774e5aa0495b9a5cc7d695fca67
Part-of: odoo/odoo#112908
Before this commit, the sidebar visibility was toggled with a css
transition, each time a change was made in the html_field.
Additionally, the transition was not working properly when opening
a mailing. Because this transition was made for website and this code
is no longer being used in website and is not usefull for mass mailing
we can remove it.
task-3100202
X-original-commit: 21056444562e530fb811095b4805345709295ca3
Part-of: odoo/odoo#112908
Since we use `historyRevertCurrentStep` in `commitChanges`, the tour
`mass_mailing_editor_tour` break because the dropped snippet was
removed on save. We need to wait for the step created by the drag and
drop stop method (when `o_we_already_dragging` is removed).
task-3052658
X-original-commit: 2d09c9663a0e6b44927f0b74235973a1925d3e22
Part-of: odoo/odoo#112908
This commit fixes two issues:
If the user click on a form tab (e.g. A/B Tests) before `toInline`
finishes, `toInline` would not be able to work properly. The reason
is that a parent element is being removed by owl when changing tab.
Similarly, changing the view from the breadcrumb could save a wrong
version in body_arch as the `toInline` could not fully finish because of
the same reason (a parent element being removed).
To solve that issue, this commit inline the `body_html` from another
iframe appended in the body.
This fix also ensure:
- no stale state for the body_arch
- no dependency of owl rendering lifecycle
task-3052658
X-original-commit: f429e8465adcddac5a24d8e178b39f1d20bfe15c
Part-of: odoo/odoo#112908
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
The UI elements related to table creation and edition are no longer
present in the toolbar, as the Wysiwyg and SnippetEditor instances
remove the `#table` div section from toolbar.
Furthermore, the OdooEditor instantiates a TablePicker instance to be
appended to the tablepicker dropdown menu under the (inexistant) #table div
in the toolbar.
This commit removes dead code related to table creation/edition via the
toolbar.
task-3074598
Part-of: odoo/odoo#111131
When we change something in the DESIGN tab of mass_mailing, we edit a
stylesheet. This means we need to flush the rules cache so
convert_inline applies the new rules in its conversion.
opw-3114599
closesodoo/odoo#111778
X-original-commit: 4ebf106e65ae4901c03c76606a05d8cd2e0790d7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
The lack of a default `options` parameter for `toggleLinkTools` led to a trace
when this method was called without parameters.
This method was introduced by [1].
This commit fixes it by adding an empty object as default parameter.
[1]: https://github.com/odoo/odoo/pull/106796/commits/862d93f9eef16ec45b0d27b246fae560f7feaf1e
task-3149496
opw-3149496
opw-3151829
closesodoo/odoo#111222
X-original-commit: 24293e2a3217d0b851a3ab1c083f2984efb31d60
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
Text style and text size drop-up were not fully visible due to overflow.
After this commit:
Added a scroll property to give accessibility to the items.
Task- 3100123
closesodoo/odoo#110547
X-original-commit: dbe410fdc93b1eb89d70c9b2a51e81b0075147d4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The basic "Plain Text" template does not have the sidebar and
therefore cannot use the link tools that are in it and must use
the link dialog instead.
Task-3128388
Task-2889670
closesodoo/odoo#110089
X-original-commit: 399e5919c18145371791092868839a5ef11209a2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since [1], the /link and /button commands did not open in the dialog
anymore and used the sidebar instead. This was wrong for the "Plain
Text" template which does not use the sidebar, and was otherwise
confusing as the main effect of the command would be to focus in the
sidebar.
Task-3128388
Task-2889670
[1] https://github.com/odoo/odoo/commit/61f7366d686b353ae9614285370e952253ec067c
X-original-commit: 44c9be11f1bc5451adc76a69862e7e513c2d9bba
Part-of: odoo/odoo#110089
In this commit, we will convert all the customisations of the kanban view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of kanban views. This allows us to define a
button that is always visible in a kanban view.
Taskid: 3082390
Part-of: odoo/odoo#106732
Pulinckx Pierre (PIPU)