Like in debug mode on optional field on tree view, show technical name on export view.
closesodoo/odoo#73898
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is, to add keyboard shortcut
to multiple actions.
So in this commit, added keyboard shortcut to several actions
in project, sale_project, web_calendar and added smart action
in command palette on statusbar.
task-2655790
closesodoo/odoo#79805
Related: odoo/enterprise#22267
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before that, uploading a file from a kanban was adding res_id=0
Was missing from 5e81850ea6
closesodoo/odoo#82101
X-original-commit: 6b4b68a2682a233ca058f3b89ea0aa096061c0eb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In owl 2, the t-on directive is no longer supported on components. The
way to handle events on components is to give them a callback as a prop.
This already works in owl 1, so this commit prepares the code for an
easier migration in the future by removing the "dropdown-item-selected"
event and converting the code that was using it to use the new paradigm.
closesodoo/odoo#80684
Related: odoo/enterprise#22722
Signed-off-by: Géry Debongnie <ged@odoo.com>
The motivation of this commit comes from breadcrumbs.
Breadcrumbs work as follows: for each controller in the stack of
the ActionService, there is an entry in the breadcrumbs. Except
for the last entry (which corresponds to the currently displayed
controller), the value to display is computed by the ActionService
and stored in this.env.config.breadcrumbs. For the last entry,
we use the displayName set in this.env.config.
When a view wants to update its displayName (e.g. the form view
when we switch to another record), it updates the displayName in
the config, which thus correctly updates the breadcrumbs. However,
this doesn't change the internal values in the ActionService, so if
another controller is stacked over the current one, the penultimate
entry is wrong. To update the internal state of the ActionService,
the event 'controller-title-updated' must be triggered as well,
which is cumbersome. Note that we don't really face the issue yet
because among already converted views, none of them need to update
its displayName in the breadcrumbs.
This commit aims at uniformizing the way the (n-1) first entries
and the last one behave, by making the "breadcrumbs" key encode
all breadcrumbs entries (the n-1 first ones, and the last, current
one). We also replace the "displayName" key by "getDisplayName"
such that it uses a single source of truth, located in the
ActionService, and we provide a function "setDisplayName" to update
it. Finally, this commit introduces the notion of "default config"
which ensures that standalone views, or views in tests, have a
valid config with expected keys.
closesodoo/odoo#81031
Related: odoo/enterprise#22799
Signed-off-by: Géry Debongnie <ged@odoo.com>
Put "Sign Now", "Send" and "Share" into the dropdown menu of "Action" button when the window is too small
Add add "Send" "Sign Now" and "Share" buttons in the list view
Make green saving Kanban in the center of the screen when the window is too small
Change the order of buttons for signature popover
Make "width: 30%" css only for buttons for signature popover to avoid text overflow
change 'Adopt and Sign' to 'Adopt & Sign'
before this commit: there are some overflow and misalignment for buttons
task-2630720
closesodoo/odoo#79292
Related: odoo/enterprise#21671
Signed-off-by: Arnaud Joset <arj@odoo.com>
Before this commit, the FieldDomain (using the DomainSelector)
didn't work well for manual edition of large domains (i.e. via the
"code editor"). For instance:
- the editor was an input, so limitated to 1 line
- the user friendly representation of the domain was redrawn each
time the input was blured (we don't need this, and it flickers)
- the count (search_count rpc) was recomputed at blur as well
(could thus freeze the interface)
This commit fixes those issues as follows:
- use a (automatically resizable) textarea instead of the input
- do not format the content of the textarea when it is blured
- do not update the user friendly part of the widget when the
textarea is blured
- do not recompute the count when the textarea is blured
- add a button to allow to manually re-compute the count
For both debug and non-debug mode, we also no longer wait for the
count to be fetched to render the widget. We display a spinner
until the rpc is done.
Task 2619505
closesodoo/odoo#79886
X-original-commit: f4e3a754a1b66dd95fa3bfb50ec1fb8ac98864ed
Related: odoo/enterprise#22295
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since wowl framework is merged pager hitbox area is reduced and harder
to hit, with this commit we increase pager hitbox area.
task-2610578
closesodoo/odoo#78006
X-original-commit: ff788c20e9582adfb387d7111218a26b29519a70
Signed-off-by: FrancoisGe <fge@odoo.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
The pivot and graph views have been rewrote in owl in [1]. However,
the former implemention has been kept as it is still used in some
cases (e.g. board application, studio, PieChart widget), but they
are lazy loaded [2].
Before this commit, both the new and former implementations mostly
shared the same DOM (in particular, their root element had the
same classnames). It means that the scss rules of an implementation
might interfer with the other, and vice versa.
This commit adds the "legacy" keyword in the root classnames of
those views, and properly namespaces the scss rules of legacy views
to properly dissociate the style of new and legacy views.
For the pivot view, we re-used the same scss file, so in this
commit, we duplicate it (one for the new view, the other, lazy
loaded, for the legacy view).
[1] 0134495ba5
[2] bd3cf85c841168dfd87f7166b545dd00d9b38bf4
closesodoo/odoo#77323
X-original-commit: 3862d5aae1df72d3585f915e8a2a2626322e74ad
Related: odoo/enterprise#21223
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit replaces the control panel dropdowns with the new <Dropdown/> component, in order to get consistent through the new/legacy views (because the current Odoo version is in a state where some views uses the new infrastructure and some others are still not converted - see odoo/odoo#73311).
The diff seems massive, but it is mostly due to tests adaptations.
closesodoo/odoo#77001
X-original-commit: d679cd0d8ba9a2420e81a42a698763e9be2327e1
Related: odoo/enterprise#21077
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When an event is currently being inspected by the user, i.e. the popover
is displayed and the user clicks somewhere else on the calendar, we do
not wish to open the quick create menu, only close the popover.
However the code that handled that case was not adapted to the regular
calendar view, only the one from the calendar app and would remove all
data currently displayed.
This commit fixes that issue.
TaskId-2652219
closesodoo/odoo#76939
X-original-commit: ea5c7b643be8c902b03a2ae175c051c479e45ed9
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With the new OWL view infrastructure introduced by 0134495, tooltips for the view switcher are not consistent across the different views. The converted views show a popover component, the legacy views show a browser tooltip.
After this commit, the view switcher's tooltips are always a popover component.
closesodoo/odoo#76444
X-original-commit: ad7db83e6dcf4c124234a3c611b84012f898acd0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
We refactor the action service and allow the legacy and new views to share
a global state within a same action.
We introduce two new components View and WithSearch along with
the search infrastructure: ControlPanel, FilterMenu,...
Part-of: odoo/odoo#73311
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
This commit adapts the "old" Owl Datepicker to work with the new Owl
web client. The behaviors have been mostly preserved (i.e. working
with the bootstrap datepicker) and simply adapted to make use of the
new services and registries.
The previous datepicker template and tests have been marked as "legacy".
Part-of: odoo/odoo#73311
Purpose
=======
Time Off : New Dashboard, Accruals feature, Public holidays, New time off type configuration view.
- Review of Dashboard
- Accrual feature : Currently, when you create an allocation, it's possible to create an
Accrual, but there is no appraisal Plan. An Appraisal plan is use to define steps of accruals
for each employee.
In Belgium, we use accrual Allocation for European Leaves, or compensatory hours, it's a
simple use case. But in USA, it's possible to change the calculation mode each year.
Also, in USA, it's possible to deal your accrual plan when you arrive on the company. It's a
HR Officer task to create the right Accrual allocation for each new employee.
- Public Holidays :
Improvement of global time off feature located on Working hours calendar. Now, Time off
application have to manage Public Holidays.
- Review of Time Off type configuration
COM PR: https://github.com/odoo/odoo/pull/72511
ENT PR: https://github.com/odoo/enterprise/pull/19157
UPG PR: https://github.com/odoo/upgrade/pull/2791
TaskID:2475413
closesodoo/odoo#72511
Related: odoo/enterprise#19157
Related: odoo/upgrade#2791
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Before this commit, when loading a view containing a searchbar on a
tablet, the device's keyboard is appearing once the searchbar's field is
autofocused.
Thanks to the backport of the mobile OS detection (see PR
odoo/odoo#75455 ), we are now able to properly target mobile OS
(independent of the screen's resolution) instead of only small screens.
closesodoo/odoo#75880
X-original-commit: b1a7296f060811153039ef73140e78ea702088a1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit, the sync buttons refactored in https://github.com/odoo/odoo/pull/68700 would appears in all calendar views (sale,time-off,...).
This commit only displays them in the calendar event view.
closesodoo/odoo#75702
Taskid: 2633415
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: web, website
This commit redesigns the editor toolbar improving its visual appearance
and introducing substantial changes wherever it is rendered.
== "Into-sidebar" design
The grid layout has been refined, improving its components allocation.
For the sake of visual simplification, "list-type" buttons have been
unwrapped from their original dropdown. For the same reason the button
to create a new table has been removed (users will have to use the
command-bar to create a new table).
Table's options have been moved to a section "ad-hoc", visible only when
a table is selected.
== Floating design (backend only)
The toolbar is now white to match the command-bar design.
In order to simplify frontend inheritance, the floating toolbar now uses
grid layout.
== Colorpicker
The generic code necessary for each design has been moved from
'wysiwyg_snippets.scss' to 'wysiwyg.scss'.
The style is now controlled by css variables allowing to customize
critical design properties without the need of SCSS overrides.
By default the design is white(-ish) to match the floating toolbar,
while in 'wysiwyg_snippets.scss' the variables are customized to get the
typical sidebar's dark feel.
Note: despite the task main objective was just to improve/fix the
design, this aimed to simplify design inheritance and reduce the css
too. While inheritance has been improved reducing the amount of
overrides, the attempt to reduce the css partially failed (in the final
lines count must be considered that a new sidebar section has been
created).
The reason is that we currently suffer from a deep and complicated
inheritance structure for this component. The xml template uses default
bootstrap classes that are styled differently depending if loaded in a
community or enterprise environment. This approach leads to overrides
that must cover all the scenarios while further customization must be
taken in account too 'cause the toolbar can be rendered into the sidebar
with a totally different design.
A possible solution would be to detach from bootstrap directly in the
lib using custom classes names, and then @extend these classes
differently according to the current environment but probably not a good
idea as we want the toolbar to use bootstrap for in-website editors (so
they can match the theme correctly) but this has to be reviewed as well
anyway. To be checked.
Part of https://github.com/odoo/odoo/pull/73565
task-2496339
closesodoo/odoo#73565
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Purpose
=======
Review the UX of the 2-factor authentication flow in order to make it more clear
and easy to use.
Specifications
==============
This commit applies multiple rewording of instructions, button, etc. Tests have
been adapted accordingly.
It also adds an 'invite to use two-factor authentication' flow that will
send an email to the selected used to redirect them their account security
settings.
- If portal is not installed yet, the user is redirected to his account security
settings in backend.
- If portal is installed, the user is redirected to /my/profile if them are
portal user. Otherwise, the redirection is still done at backend side.
As the backend view of auth_totp wizard is used at frontend side, copyclipboard
widget has to be rebuilt at frontend side (click event, style etc..).
As API key section is now displayed only on debug mode, test urls have been
adapted accordingly.
Task-2487630
Part-of: odoo/odoo#71142
PURPOSE
Allow to group records by many2many fields.
Use case: turn the user_id m2o field on project.task into a user_ids m2m field
in order to assign multiple collaborators on a task
SPECIFICATION
Add many2many fields to the 'list of groupable fields'.
When grouping a set of records by a many2many, records linked to multiple
records of the comodel will essentially be in multiple 'groups' (even though
those are not really 'groups' anymore).
There will also be a "null" group, for records that have an empty value of the
many2many, like "unassigned" records.
Example: grouping a project.task linked to 10 res.users by the user_ids
many2many field, the project.task will be 'rendered/considered/displayed' 10
times, once per res.users.
Kind of like if we grouped the m2m relation table instead.
When grouping by a m2m field:
- listview
editing an instance of a record also updates each other instance(if any)
- the same goes when scheduling an activity, etc.
disable deletion
- the risk here is that the user might expected that this will 'unlike'
the record from a specific record of the many2many field
disable archive/unarchive
- kanban
disable drag&drop between groups
disable deletion
disable archive/unarchive
- searchview
display many2many fields custom groupby dropdown
With this commit, we also support groupby many2many field in mockServer so that
test cases are written based on that.
task-2508608
closesodoo/odoo#74985
Related: odoo/enterprise#20192
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit is a refactoring of the command palette. It aims to improve
its design and make it very easily configurable. For this, we added the
config props allowing the command palette to know what to display.
The config of a palette command is composed of:
- categoriesByNamespace?: list containing all categories according
to their namespace;
- emptyMessageByNamespace?: dictionary having for key a namespace and
for value the message to display if there is no choice available;
- footerTemplate?: template to display in the footer;
- namespace?: namespace to add in the search bar;
- placeholder?: placeholder of the searcher;
- providers: list containing all the providers generating the commands
to display;
The providers are the only information needed in the config. The rest of
the config is optional.
This commit also adds the possibility to open a custom command palette
using the command service. For this, you just have to call openPalette
and give it the required config.
If the command action returns a config, the command palette will
not be close and will use this new config.
Task-id: 2622240
Part-of: odoo/odoo#74933
Before this commit, the calendar filter was a little bit limited: you could add filters to only display events related to these filtered records or display all events.
If you wanted to select all active filters, we had to check all these individual filter.
This commit introduce the possibility to select all existing filter at once or to unselect them. It is quite convenient when a lot of filter are displayed but unchecked.
Taskid: 2484335
Part-of: odoo/odoo#68700
We prepare the rewritting of the search components for the new weclient:
we rename some legacy templates to allow the new components to use the
natural template names.
Purpose
The aim of the current task is to adapt the design of this new widget to the
list and kanban views.
SPECIFICATION
Kanban
when there is only one record set in the m2m field, display it like a
many2one_avatar widget when there are two or three records set in the m2m
field, display the avatars next to each other when there are more than three
records set in the m2m field, display the first two avatars, then a grey circle
with +X in it (where X is the number of records beyond the first two), when
hovering the +X avatar, open a tooltip with the list of the remaining records
the display order of the records is the same as the order in the m2m field
the avatars behave like in the other avatar widgets (i.e. darkens on hover and
clicking on it opens the chat) except the +X avatar that does not darken or has
a cursor:pointer; on hover and is not clickable
List
same specs as for the kanban view, with the difference that the widget displays
up to five records instead of three when the widget is editable display it like
the current formview version of the many2many_avatar_user widget (i.e. tags
with avatars)
task-2563591
closesodoo/odoo#72166
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Currently, the time in popover of the year view does not appear
with the title due to record.allday is undefined instead of false
So in this commit, check if record.allday is not exist then display
the time infront of the title instead of after the title.
Related enterprise PR: https://github.com/odoo/enterprise/pull/19134
closes odoo/odoo#72440
Closes: #72440
Taskid: 2502339
Related: odoo/enterprise#19134
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Need to check and mark legit uses of HTML as Markup. Also fix some
title formattings which are not great (mostly around translations) and
de-escape titles which don't need to be escaped anymore.
Descriptions which need to use markup should be explicitly marked as
such. Update examples test to check that both Markup and String
descriptions work fine.
`escFormat` had to be modified quite a bit and ended up requiring
being its own Markup-adjacent type: if the `sprintf()` result is wrapped
in a `Markup`, then what happens is we first decide to escape because
the object returned by `escFormat` only has a `toString()`, then that
blows up because `toString` returns a non-primitive object and the
regex used to implement `_.escape` is very very unhappy.
`escFormat` could return a `Markup` object but then it wouldn't be
lazy anymore which would rather miss the point.
Therefore implement `[_.escapeMethod]` on the thing, such that it
doesn't get escaped, because it's safe (ish).
Also as a result the icons probably don't need to be markup-ed. Oh
well shouldn't really matter.
Popover has some style by default (eg. padding), but it is not always desirable
(eg. if the content has a scrollbar, having padding to the right of the
scrollbar is not good).
-> Add a class to allow overriding the default style in the legacy popover.
closesodoo/odoo#73655
Note: the new popover already has this prop.
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to:
- Improve the design of the command palette
- Add few data-command-category and data-hotkey
- Scrolling through the command palette dropdown with the up/down arrows
should loop
- Moving the mouse over the palette command no longer causes scrolling
Task-2590390
This commit adds a sum field description when hovering the quantity at the end
of a progressbar. The description is the label (translated string
representation) of the field used for the sum.
Task-ID: 2243913
PR odoo/odoo#69380
Before this commit, when browsing a filterMenu with the keyboard, the CustomFilterMenu
was not focusable. This is because its root node changed from `button` to `span` which is not
focusable by default.
After this commit, the CustomFilterMenu is focusable and the root node has been replaced back by a button
closesodoo/odoo#72738
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit implements improvements in the layout designer, such as addition of a new custom background, adds custom report footer and company details.
task-2355704
closesodoo/odoo#66860
Related: odoo/upgrade#2275
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Since odoo/odoo@1971bf3 the customised dropdown in the pivot view (the one that opens its submenus horizontally) cannot open at all its submenus.
As the correct behaviour cannot be restored without reintroducing the +300 scss lines that has been removed, this commit applies a temporary fix that *changes* the design of this dropdown. Now, its submenus will open vertically, like for the groupby menu near the search bar.
The final dropdowns design is currently ongoing within the taskid: 2578926
closesodoo/odoo#72640
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Previously, we removed the crash manager and moved its responsibilities
to the error service.
Because the crash manager was used in both the frontend and backend, and
because the infrastructure code required to use the error service in the
frontend hasn't been written yet, the crash manager has been moved to
the frontend assets where it is still needed in the interim. Most of the
logic of the crash manager has been moved to public_crash_manager (as it
is now the only crash manager and it doesn't make sense to keep the
inheritance hierarchy).
References to the crash manager in the backend were adapted where needed
or removed where they were no longer useful.
closesodoo-dev/odoo#943
Related: odoo-dev/enterprise#174
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adapt breadcrumb 'current' entry color according to its context.
If other entries are visible and clickable, 'current' will be muted
(default). If 'current' it's the only entry, then it acts as view's
title and it will be styled more prominent.
Overall colors review to achieve WACG standard compliance.
https://www.w3.org/WAI/standards-guidelines/wcag/
Current contextual colors work fine when used for backgrounds but fail
WACG tests when are used for text.
Unfortunately Bootstrap use the same palette in both scenarios without
providing effective control over text colors.
The 'text-emphasis-variant' mixin, indeed, allows to darken a color by a
certain amount, but since the amount is not customizable per-color the
final result is always either too dark or too light for colors that are
not used as a reference.
This commit will define a specif SCSS map called `$o-theme-text-colors`
that mirrors the default '$theme-colors' structure and contain
fine-tuned values to be used specifically for text.
In order to keep the same classes names, we customize the default
'text-emphasis-variant' mixin, instructing it to first look for our
fine-tuned colors and eventually fallback to default.
This commit will also adapt all the modules that use to hardcode text
colors in SCSS rather than using default utility classes. We handle this
using different approaches:
- Use utility classes whenever is possible (eg. 'text-info')
- If apply the class directly is not possible, '@extend' it in SCSS
- If '@extend' is not ideal because of code complexity (eg. ':hover'
interactions), use the new 'o-text-color([color name])' scss function.
Florent de Labarre