| Age | Commit message (Collapse) | Author |
|---|
|
Since the merge of JQuery 3, the building of systray icons is non
deterministic.
After this fix, the menus are loaded correctly in order.
Task-ID: 1960741
closes odoo/odoo#32382
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The commit https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898 has
modified how libraries are loaded at several places and has
introduced a bug in sale_subscription_dashboard where the
libraries are no longer loaded at all. We fix that situation
by calling super in the willStart method of AbstractAction
that inherits from Widget. Abstract actions can now also
benefit from the mechanism present in Widget willStart.
|
|
|
|
The commit https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898 has
modified how libraries are loaded at several places and has
introduced a bug in sale_subscription_dashboard where the
libraries are no longer loaded at all. We fix that situation
by calling super in the willStart method of AbstractAction
that inherits from Widget. Abstract actions can now also
benefit from the mechanism present in Widget willStart.
closes odoo/odoo#32209
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
|
|
|
|
To reproduce:
1. go on list view
2. open record in form view
3. come back on list view
4. switch to kanban
5. open record in form view
6. click on breadcrumb
Before this rev. we were back on the list view, and not the kanban view.
This is due to the fact that the breadcrumb was not updated when switching view,
(if a controller was already existing) so the form view control panel breadcrumb
was still referencing the wrong (list) controller.
This bug appeared with the control panel refactoring, which is now managed by
the view itself (and not the action manager as previously).
Task 1932646
closes odoo/odoo#31598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This error is there to help developpers realize their view has not
been loaded due to an error.
However, we have cases where we define actions containing views
that only exist in Enterprise to avoid creating an entire bridge
module just to add one view to an action.
The error was triggered in this case which resulted in a red build
for the click all runbot test, even though this was not really a
true error, as it was intended.
This commit changes the error to only appear in debug=assets such
that it will no longer put the click all runbot tour red while
still providing help for the developper trying to debug his view
since he will need to be in debug=assets to debug his view anyway.
closes odoo/odoo#31884
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
closes odoo/odoo#31790
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
|
|
* web_editor, website, survey, im_livechat
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
|
|
closes odoo/odoo#30045
|
|
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
opw-1928512
closes #30239
|
|
On an instance with only web installed.
A non-admin use had an error as trying to open the first app (which does not exists)
closes odoo/odoo#29687
|
|
The 'Actions' menu displayed in the control panel (aka sidebar, or
toolbar), wasn't displayed anymore since the control panel
refactoring of 4cd379cf6e. Rev. c1752b834 correctly made it appear
again in list and form views. However, there was another issue as
the additional model-related items (like Print, or custom actions)
weren't fetched anymore. Thus, the sidebar only contained the
default 'Export' and 'Delete' actions. This rev. fixes the second
issue.
fixes #29546
closes odoo/odoo#29633
|
|
|
|
|
|
There was a traceback when reloading the webclient with an act_window and an
empty id in the URL (ex: after saving Settings). A `read` without id was
peformed when loading data instead of a `default_get`.
Before rev. odoo/odoo@40dd121 the action environment was generated by the
ActionManagerActWindow, which was currently defaulting the `currentId`.
Now that this is not the case anymore, the `loadState` should have this responsability.
Task 1902826
closes odoo/odoo#29411
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closes #29190
|
|
From a standard view with the main menu (what is called a target=current action)
open a target=fullscreen action
Then, go back to the first action, with the breadcrumbs for example
Before this commit, the original view was displayed fullscreen,
which impaired business navigation because the main menu was not there anymore
After this commit, the original view has the main menu
OPW 1906373
closes odoo/odoo#29096
|
|
|
|
|
|
Before this commit, when the user is in a form view (edit mode) and
click on a stat button, a new action is added to the action stack. When
the user then comes back to the form view by clicking on the breadcrumb,
it is supposed to be in readonly mode. Before this commit, this was not
the case.
This bug comes from the action manager refactoring, which removed the
view manager. With this commit, we add a new action lifecycle method
which is called when the action is restored.
Note that this commit implicitely changes the semantic of actions with
'target=inline'. As far as I can tell, this only applies to the settings
form view, which can easily be fixed by overriding the restore hook.
closes odoo/odoo#28663
|
|
closes odoo/odoo#30614
|
|
|
|
|
|
closes odoo/odoo#29439
|
|
|
|
|
|
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
|
|
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closes odoo/odoo#28766
|
|
Before this commit, when an element with access key has a CSS
position absolute , pressing the key 'ALT' to show the access
key overlay may break the position of the element.
This is due to altering the CSS position of the element which the
overlay is attached to: it becomes `relative`, so that the overlay
takes the whole size of the attached element.
In case of an absolute element, it should not become relative,
otherwise its position on the document may be completely different.
Since the overlay has position `absolute`, if its parent has also
position `absolute`, then keeping both with position `absolute` will
let the overlay take the size of the parent, without changing the
position of the parent.
Task-ID 1885445
|
|
(mainly views and ActionManager)
- add missing docstrings
- fix typos
- correctly order functions and imports
- put functions in correct sections
- stop using 'event' as argument of handlers
- don't call handlers directly
- remove trailing spaces/tabs
- move module created in stable version to its own file
- follow js guidelines in general
closes odoo/odoo#28024
|
|
There used to be no processing done at all when loading the client
from an url missing a menu_id and from which the menu could not
be inferred from the action_id. This resulted in the app name
button in the menu being empty but still present and not bound to
any action. Clicking on it triggered a traceback.
This commit stops ignoring the case when the menu cannot be
inferred from the action and hides the entire menu and submenus
for this particular action. They will be restored when entering
an action from which a proper menu can be inferred.
closes odoo/odoo#27791
|
|
Revision on https://github.com/odoo/odoo/commit/b7cf456560dc4fd7c1217ba90f0b5609466ede50
The commit above assumed the function `change_menu_section` was
mistakenly removed. However, it was turned into a handler function
and renamed according to our JS guidelines `_onChangeMenuSection`.
This commit removes the duplicated logic by removing the
function `_onChangeMenuSection` and using `change_menu_section`
as the handler for the bus event `change_menu_section`.
closes odoo/odoo#27809
|
|
Revision on https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242
The commit above changed the menu in community, so that it
looks like enterprise. To do so, it copies the menu management
from the enterprise repository to the community repository.
Some code about the home menu has been removed, since it is replaced
with the app menu in community. However, some functions have been
removed by accident, such as `change_menu_section`.
Closes #27436
|
|
|
|
Since https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242, it was possible to click on a "Shortcuts" menu item
in community which triggered a call to _onMenuShortcuts whose
implementation was only defined in enteprise
As the keyboard shortcuts are available both in community and
enterprise, we should support this menu item
|
|
|
|
* requires that current user has group_system
* only visible in debug mode (?debug)
* available at login or via debug menu
* special systray color in superuser sessions
Closes #27254
|
|
Before this rev. the lazy loading of views was correctly handled if there was
only one action in the action stack (which is usually the case when performing a
F5, the main use case of the view lazy loading).
Nevertheless, it might happen that the lazy-loading is used in top of other
actions (when performing a `doAction` with a form view for an action with
another view as first view, i.e. when leaving Studio while editing the form view).
The controller was `unshift` in the case (put in the first position of the
controller stack), which is not correct.
This causes the breadcrumb to be misordered and a traceback occured when trying
to access a breadcrumb element.
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
task-id : 1873908
|
|
It excludes a lot of 'noise' when we do not set automatically access keys to all
the skipped items, this allows a better focus on actions when using the keyboard.
|
|
|
|
On MAC, some characters can only be typed using the ALT+Number that was
reserved for the menu access keys.
There is a system in place to collect the ALT+Number keys and force the
activation of the shortcut to make the experience better for all users
across all machines.
This fix remove this system that collects ALT+Number or other keys on MAC
Ticket number : 1887171
|
|
This was necessary because the rendering was always determining
which app item should have the class 'active'.
This was an issue with the 'Click Everywhere Test': at the beginning
of the script, it gets the jQuery element that matches all nodes
`a.o_app` in the app menu. When an app item is clicked, it re-renders
the whole app menu, so that older referenced nodes are detached from
the DOM. As a result, clicking on them no longer works, because it
never triggers the MouseEvent `click .o_app`.
This commit fixes the issue by rendering the whole app menu once.
When an item in the app menu is clicked, it dynamically changes
the `active` app.
|
|
|
