Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@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
- Have a slow network
- Click multiple times on the 'Check-in' button
Multiple attendances are created.
The view refactoring introduced in 9de1bc0eef changed the
element to a `<a>` tag, on which the `disabled` attribute has no effect.
We introduce a `debounce` instead.
opw-1941647
closesodoo/odoo#31178
When running in kiosk mode, it is necessary to refresh the interface
once a week since the session is garbage collected.
The garbage collection method `session_gc` relies on the last
modification time of the session file. However, the session file is only
saved when the field key `should_save` of the session request is `True`.
This happens when the session is `modified`, i.e. an item on the cookie
is set.
In practice, the session is saved at each reload of the page. Regular
RPC calls, such as the one used in commit 6e1b660f9c, do not
trigger a modification of the session file. Therefore, we create a new
route which explicitly sets the session as `modified`, which ultimately
triggers a `save` in `get_response`.
opw-1917254
closesodoo/odoo#29919
to ControlPanel/Search view refactoring.
The ControlPanel being now inside the DOM of client actions, those
existing widgets needed to be adapted (in the way they define if
and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
=========
PURPOSE
=========
{Any employee can work on a PoS session, even if he has no user. This decreases the cost of PoS App.}
We are not competitive enough on the PoS Market because customers have to pay one user per cashier while they expect to pay one user per cash station.
===============
SPECIFICATIONS
===============
pos.config
- Add a checkbox : "Login with Employees"
- If set to TRUE, an "Allowed Employees" many2many appear
- If employees many2many is empty, all employees can log on this PoS
- If set to FALSE, can only log in with the currently logged user
hr.employee
- The barcode and pin fields were be moved to the hr.employee
- Set a barcode (not pin) by default at the creation of any employee
- No Employees module with PoS > dependency to hr
Open the PoS if "Log in with Employees" = FALSE
- Same behaviour than now, when I open the PoS, I'm logged in with the current user and can start working at once. The only difference is that it is not possible to switch users anymore.
- The button to close the session is visible
Open he PoS if "Log in with Employees" = TRUE
- When I open the PoS, the first screen I see is the login screen.
(a) I choose my employee and enter my pin code (if there is pin code on my employee, otherwise not required) (I can only see employees that have access to that PoS)
(b) I scan my barcode
(c) I scan my rfid card (future development)
- When I click on the employee name, I can log in with another employee
- If the employee is linked to a user that has the pos user/manager access right, I can see the button the close the session. Otherwise I cannot close the session (and thus cannot access backend).
- Add field employee on all records created by PoS (and replace the field user by that one) (on pos.orders)
Lock Screen
- Improve the PoS Interface
- Add a new feature to allow to "lock" the session. When a session has been locked, the user/employee has to re-log-in to access the PoS
- When I try to re-log-in, by default suggest the last employee logged in in the login screen
Migration
Plan a migration strategy > barcode and pin is now on the employee and not on the user anymore
closesodoo/odoo#28567
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
- Scan a barcode for employee 1 in kiosk mode
- At greetings message, scan a barcode for employee 2
2 attendance entries are created for employee 2 instead of 1.
When scanning the barcode for employee 2, the event listener
`_onBarcodeScanned` is still active on `KioskMode`. Therefore, the RPC
call to `attendance_scan` is performed twice.
We deactivate the event listener after scanning, and reactivate on
`KioskMode` only if there is an issue. This is sufficient since the call
to `do_action` in `GreetingMessage` will create another instance of the
client action. In `GreetingMessage`, we add back the redirection to
`KioskMode`.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Linked to Task ID 1878251
opw-1878632
opw-1888402
closesodoo/odoo#28150
If the search returns more than one result, the rendering of the message would
crash (SingletonError when accessing check_in field value).
Use the same order and limit as both search before and after
Courtesy of David Tran
Closesodoo/odoo#28055
- Open the Attendance kiosk mode
- Scan an incorrect barcode
It's not possible to scan any barcode anymore.
If the barcode is incorrect, we need to add back the event listener.
Moreover, the RPC introduced with bbc7e9586d is not necessary if
we retrieve the barcode thanks to the existing RPC call.
opw-1878632
opw-1888402
closesodoo/odoo#28354
Christophe Simonis