| Age | Commit message (Collapse) | Author |
|---|
|
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
closes odoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
|
|
We need to be able to change an expense report before submitting it, for
this we add a new step in the expense process (a draft state for the
expense sheets).
Task #41700
Closes #24806
|
|
Currently the distinction between expense officers and expense managers
doesn't make sense because they both have the same rights.
This commit aims at making a clear difference between an officer and a
manager.
After this commit the rights will look like this :
* Expense Manager :
- See and approve any expense
* Expense Officer :
- Can see and approve the expenses of employees in his department
or employees for which he is the manager (field parent_id on
hr_employee)
- Cannot approve his own expenses
* Simple user :
- Can only see his own expenses
- Can only send his expenses to a manager (either the manager of
his department, his direct manager [parent_id field] or an
expense manager)
Related to task #51520
Closes #23033
|
|
Expense users should not be able to create activity types. This is limited to
managers like in other applications allowing to create activity types.
|
|
This commit improves expense flow management through a better integration
of activities and addition of automated activities. Several things are done
in this commit :
* expense sheet (report) model do not inherit from mail.activity.mixin.
This commit adds the inherit so that expense users and managers can now
schedule and manage activities on expense reports. This will help them
in their daily job;
* automatic activities generation is added for expense reports. Activities
are generated for approval. They are also automatically set as done when
validating or unlinked when refusing or resetting to avoid bloating users
with unnecessary activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages and tracking
that were implemented to warn people of expense reports to approve.
This commit therefore
* simplifies the tracking as tracking to confirm reports is not necessary
anymore;
* removes to approve subtype on report model as well as its parent subtype
on the department. This allows to simplify chatter in hr_expense app;
|
|
Also rename product.uom.categ into uom.category to
give it a decent name.
|
|
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
|
|
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
|
|
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
|
|
NB:
- The option no_delete is not working, a fix will come from chm
- The many2many widget on a sheet creation is not working correctly as
the called command is a (1, id, values) without a (4, id, _) before.
A fix will also come from chm, but a disgusting hack has been
provided for this particular case (to remove after chm fix)
|
|
|
|
usability. Concept of expense sheet removed. Was PR #7387.
|
|
|
|
Major changes:
- No use of UoS anymore
- No journal since invoicing is managed in Sale
- No invoicing from timesheet
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
|
|
|
|
depending on which module the moved code belongs to. This allows to remove references to project in account module. Also added some improvements in project when deleting a project (delete account if void) or when deleting an account (delete project if void).
|
|
bzr revid: dle@openerp.com-20121122104504-ezgj2666zkhgybpj
|
|
bzr revid: fp@openerp.com-20121010192927-6ud5e3zvhp5gabip
|
|
bzr revid: cha@tinyerp.com-20120926125325-xshc34cau22qnc40
|
|
bzr revid: fp@tinyerp.com-20111212181113-mhnnbps3ip8ls6pp
|
|
bzr revid: fde@openerp.com-20101230122428-wqsf7qcck7rasbfp
|
|
bzr revid: fde@openerp.com-20101229143849-03lpmdpu5fkc6e86
|
|
bzr revid: hmo@tinyerp.com-20101229085716-y13ctpn3ptenrfl0
|
|
bzr revid: amp@tinyerp.com-20101022085331-qqvd1wj9io4y3di1
|
|
bzr revid: dbr@tinyerp.com-20101007071157-z52414z1sz9h85qh
|
|
bzr revid: dbr@tinyerp.com-20101006125128-85urgfc27zuhvcx7
|
|
bzr revid: amp@tinyerp.com-20100913131824-1au2kx7na9czsh4z
|
|
bzr revid: amp@tinyerp.com-20100906063006-gcuxdswiunwokvn4
|
|
bzr revid: amp@tinyerp.com-20100901132905-hslnywxf4zxogxdo
|
|
bzr revid: vir@tinyerp.com-20100813133645-w8nex9k1he2zjq9h
|
|
bzr revid: dbr@tinyerp.com-20100804085628-58nplf4yw8zp80dj
|
|
bzr revid: dbr@tinyerp.com-20100803131117-jkvf2a7pe955en2u
|
|
bzr revid: amp@tinyerp.com-20100723072243-kpex4cdgckhga46d
|
|
bzr revid: rvo@tinyerp.co.in-20100421111435-v4u8cemnfir19kh0
|
|
bzr revid: christophe@tinyerp.com-20081021153441-af1qtobtazu7rs28
|
|
bzr revid: fp@tinyerp.com-20080903224650-u1oadqv9x75atmyl
|
|
bzr revid: fp@tinyerp.com-20080903180400-df7l6wxg1zpirmmi
|
