A user without Time Off rights is now allowed to cancel their own
validated time off when:
- It's not yet started;
- No work-entries has been generated for it yet.
The time off is archived and the days taken reallocated.
closesodoo/odoo#76722
Taskid: 2643713
Related: odoo/upgrade#2843
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The stat buttons were showing incorrect values, the accrual action was
not returning, archiving an employee was no longer possible because an
incorrect state was used.
closesodoo/odoo#76468
Taskid: 2641596
X-original-commit: cc75a1233ed40cb1a4812a5f4a377b8859795b26
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Improve the departure wizard form view aswell as the flow when using it.
Removes the confirmation dialog when archiving an employee to directly
display the departure wizard.
Also changes departure reason to an html field instead of pure text.
Task ID: 2575279
closesodoo/odoo#72367
Related: odoo/enterprise#19116
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
=======
When you close a payroll (employees), there are often a lot of document
linked. Archiving an employee should archive the contract, cancel future
leaves, archive the private address
Specification
=============
Add departure date (hr):
- Add a Date field to both hr.departure.wizard and hr.employee. In
the wizard, the field is required.
- In toggle_active() method in hr.employee, set departure_date to
false when unarchive the employee.
- If user has a current running contract, a user error will raise if
user enter a departure date earlier than the start date of the
contract.
Add checkbox to set a closing date on hr.contract (hr.contract):
- In the hr.departure.wizard, set the departure date to be the end
date of runing contract. Set the states of all draft contracts to
"cancel".
Add checkbox to free car (hr.fleet):
- In the hr.departure.wizard, set end_date to
fleet.vehicle.assignation.log, if there is no end_date or end_date >
departure_date
- Go through fleet.vehicle, find records with dirver_id to be the
employee, set it to False.
Add checkbox to archive private address (hr):
- when the private address not link to a internel user, set
employee.address_home_id.active to Flase
- unarchive it after the employee unarchived
Add checkbox to cancel future appraisals (hr.appraisal)
- find all appraisals link to the employee and state in
['new', 'pending'], set their state to 'cancel'.
Add checkbox to cancel future leaves (hr.holidays):
- only consider leaves are not in state ['refuse', 'cancel'],
find leaves with to_date > departure_date, set their state to
'cancel'.
PR #42526
Task 2153106
Related: odoo/enterprise#7471
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998
closesodoo/odoo#33813
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closesodoo/odoo#29634
It seems specifications of new menus implemented at 9af6e9070a were not
totally correct and broke some Odoo conventions. New specification for leaves
application menus are now the following :
* Dashboard
* My leaves (user sees this only)
* New request (calendar view by default)
* Leaves requests (only my, list view by default)
* Allocation requests (only my, list view by default)
* Summary (only my, summary list view by default)
* Managers (HR officers or managers only)
* To approve
* Leaves (default filters: to approve, on my department)
* Allocations (default filters: to approve, on my department)
* All
* Leaves
* Allocations
* Payroll
* Leaves to report (default filters: grey kanban state)
* Reporting (HR officers or managers only)
* Leaves Analysis
* Report by Department
* Configuration
* Leaves Types
This commit is linked to task ID 1876795 and PR #26571.
When calling the function report_action from write_company_and_print_report,
it failed because all the required data from the transient model "hr.holidays.summary.dept"
were lost.
opw:803051
- added encoding to xml files
- replace search_read() with search() for _search_absent_employee()
- fixed setting first date of current month as default value for wizards
- reduce calls to <dict>.get()
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- Several Modules have been splitted into several apps
Examples :
Human Resources : Splitted into Leaves, Recruitment, Expenses, Appraisals, Timesheets, Employees, Payroll
Marketing : Mass Mailing, Events, ...
Messaging : Chat, Agenda, Notes, Address Book, ...
- Generally, the related reports have been moved in the apps, as last menu
- Also, configuration menu (no_one group) have been moved into a config root menu
exception made for the warehouse and lunch modules
- Configuration for typical frontend modules have been moved into the website settings
Related modules : Ecommerce, blog, slides, forum
- When they are present, menus like 'product' or 'customers' have been moved
ex : Customers in Sales menu, Product in POS menu
- A lot of sequences and xmlids have been added or modified in this commit
- List of apps :
1 Chat : Inbox, Channels
2 Agenda : Calendar
3 Notes
4 Address Book : The view contact is still laying in the mail module (1 app => 2 icons)
5 eCommerce : Still to define : Config + Orders Analysis + Shipping + incoming Amazon module
6 Sales : Dashboard (Sales Team Kanban), CRM, Sales (note that they are splitted into 2 submenus)
Assignation, After-Sales (Invoicing and Services), Reports
7 Point of Sale : Dashboard (POS status), Orders, Reports
8 Project : Dashboard (Project Kanban), Search (all tasks, issues), Incoming Forecasts module, Reports
Project.issue.version feature has been removed completely
9 Members : Dashboard (Members Kanban), Report, Config
10 Timesheets : Time Tracking, Approvals, Reports
11 Purchase : Purchase, Control (Products and Bills)
12 Warehouse : Dashboard (Warehouse Kanban), Operations, Inventory Control, Schedulers, Configuration
13 Manufacturing : Same menu structure
14 Mass Mailing : Mailings, Campaigns, Reports
15 Events : Events, Reports
16 Lead Automation : Campaigns, Reports
17 Surveys : Surveys, Reports
18 Human Resources : Dashboard (Departments Kanban), Employees, Contracts, Engagement (Gamification)
19 Recruitment : Job Positions, Applications, Resumes & Letters, Reports
20 Expenses : Expenses, Approvals, Reports
21 Leaves : My Leaves, Approvals, Reports
22 Appraisals : Appraisals, Interview, Reports --> Will probably be modified by the incoming refactoring
23 Payroll : Current Menu
24 Lunch : My Lunch, Manager, Configuration
25 Accounting : Same menus currently, waiting the new accounting to be merged
26 Fleet : Current menu
27 Sign : Incoming docusign module
28 No root menuitem with this sequence
29 Attendance : Attendance, Reports
Sign in/out by project feature has been removed completely
30 Link Tracker (group_no_one) : Link Tracker, UTMs
New view added : URL Shortner, which is the frontend view embedded in backend
31 Versionning : Website domain, Versions, Experiments
32 Slides (group_no_one) : Channels, Categories, Slides, Tags
33 No root menu item with this sequence
34 Livechat : Channels, History, Reports
35 Dashboards : My Boards, Configuration
36 App Store : Local Modules, Apps, Updates
Last Settings : Incoming Dashboard Settings, Sales, ...., Website Settings
General Pattern for all modules' settings :
| Module_name
|-- Settings : General Config view (checkbox screen)
|-- Record setting 1
|-- ...
|-- Record setting n
Example for Sale module
| Sales
|-- Settings : Checkbox screen
|-- Quotations
|---- Quotation Templates
|---- Report Layout Categories
|---- Contract Template
|---- Invoice Type
|-- Contract
|---- Deduplicate Contacts
|-- Delivery
|---- Delivery Methods
|---- Delivery Pricelist
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Kevin Baptiste