| Age | Commit message (Collapse) | Author |
|---|
|
Basically when someone requests a new car, getting that car ready takes
some time, this means that during the waiting period, that person is
still driving its old car.
This commit adds a field future_driver_id on fleet.vehicle to tackle
that problem and a boolean plan_to_change_car on the partner to track
who wants to change car.
+ Apply some linting to the files
This commit cleans the vehicle form view, the vehicle contract form
view, the cost list view and adds a manager_id field on the
vehicle.model which is then used as a related on the vehicle.
Task: 1930298
closes odoo/odoo#31197
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
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>
|
|
User 1 simply becomes a technical user (inactive, no password).
|
|
Purpose
=======
Currently it's impossible to know who was driving a given car at a given time.
We have some piece of information like the immatriculation date of a vehicle
or the date of the first contract. But it's not enough.
This is problematic to solve a rather common issue:
- Who is gonna pay the fine for having exceeded the speed limit?
Specification
=============
Introduce a simple model fleet.vehicle.assignation.log, containing info about:
- The driver
- The vehicle
- The start Date
- The end Date
A simple button on the fleet vehicle should be sufficient to solve the issue.
We cannot generate data from the salary package as these dates can't be predicted
at the contract signature.
|
|
This commit improves fleet contracts management through a better integration
of activities and addition of automated activities. Several things are done
in this commit :
* fleet vehicle log contract does not inherit from mail.activity.mixin.
This commit adds the inherit so that fleet users and managers can now
schedule and manage activities on vehicle contracts. This will help them
in their daily job;
* automatic activities generation is added when contracts are nearly expired
and renewal is required;
* a menu to configure activity types is added. Indeed fleet 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 posted on the
contract. Indeed currently there are messages posted on vehicles about
contracts to renew. As we now have automated activities on contracts to
remind assigned people to renew it the log can be safely removed. It will
lessen noise generated on chatter.
|
|
Create users having only manager or user rights on fleet, cannot acces \web pages, We should add the employee rights, as when we give fleet rights
|
|
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
|
|
|
|
|
|
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
|
|
Alexis de Lattre (Akretion)
ir.rule records are in noupdate data blocks to let the admin
alter them without fear of them being reset at next update.
Other records such as groups are in normal mode, so they
can be updated whenever necessary
bzr revid: odo@openerp.com-20121218232001-t425t4hi7qbmsip2
|
|
of data
bzr revid: csn@openerp.com-20121217132045-lt0b2aeubty1hrkn
|
|
and put demo_user in fleet_user group
bzr revid: csn@openerp.com-20121210162834-bej2x1m8vms87qre
|
|
be driver by default
bzr revid: csn@openerp.com-20121210140317-kg03hsk46rpzgcyx
|
|
bzr revid: csn@openerp.com-20121206142941-pmq2s4h2or1ey0nl
|
|
bzr revid: csn@openerp.com-20121206105033-6dcffqm1626jt5r8
|
|
bzr revid: csn@openerp.com-20121204162056-cacua9dw1shg5fnv
|
|
bzr revid: vmt@openerp.com-20121115160643-lc0b07n6xiaq1rl3
|
|
bzr revid: csn@openerp.com-20121004102033-mr108oy63dnmxlik
|
|
bzr revid: csn@openerp.com-20121003150419-9t3jmprmjh5b6lux
|
|
bzr revid: csn@openerp.com-20121003133811-u31kfolwiv0xer3s
|
|
bzr revid: csn@openerp.com-20121003080250-wg6faq7p9o3x23rk
|
|
Access Rights
bzr revid: dle@openerp.com-20120926151849-5mjlb5qyxj6j8d5x
|
|
bzr revid: csn@openerp.com-20120925120942-rdaiucpwmt4jl8v3
|
