Tests from hr_recruitments work luckily until now.
Because module maintenance imply base.group_user for group_equipment_manager
<record id="group_equipment_manager" model="res.groups">
...
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
and module hr_maintenante imply group_equipment_manager for hr_user
<record id="hr.group_hr_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('maintenance.group_equipment_manager'))]"/>
</record>
After this commit launch test on hr_recruitment module without any other module will works.
Design-theme repo show this error because repo tests hr_recruitment without installing maintenance
(Repo install website_* modules -> website_hr_recruitment -> hr_recruitment -> hr)
Backport-of d5b0f99943 to have runbot design-theme green
Purpose
=======
Add the possibility to create private addresses, only accessible for a subset
of users.
Specification
=============
- Add a new 'Private' partner type
- Add a res.groups in base 'Access to Private Addresses'
- Add ir.rules for the following behavior:
- Every employees/internal users can read non-private addresses
- Only users in group_private_addresses can access private addresses
- Add in base a simplified form view for private addresses
- A HR Officer is automatically granted in group_private_addresses
- Use the simplified form view to open the address_home_id form on employees
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
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.
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
- Rewrite the code to new api without changes
business behavior
- Remove old v7 backward compatibility method
- Regroup view definitions in the same xml file
- Use read_group for computed fields
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.
- remove otherid field from the model, and the reports
- reorganize several fields on the form
- removed group_multi_department group, departments are always activated,
as 3 departments are now in the datas
- departments menuitem is accessible to the hr officers and managers only
- removed all the configurations in the employee root menu
- moved payroll country module selection to payroll configuration
- removed useless fields from the form : attendance state, goals_ids,
remaining leaves, as they are accessible via stat buttons, kanban views, etc.
Conflicts:
addons/hr/hr_view.xml
addons/hr_holidays/hr_holidays_view.xml
This reverts commit 79c338dcb352be3d40118f998a76e1b7576a35da.
This commit has been done hastily without review. Moreover it
mixes changes related to different stuff.
The commit is then reverted to allow a propre review and cleaning
of the branch.
- sales_team: demo data enable sales team features to users
- hr_attendance: admin can enable attendance features from hr settings
- multi_company: if admin enable these features, she gets the
multi-company usability settings
- account: enabling multi-currency functionalities enable pricelist
functionalities
hr add a simple kanban view that is updated by the various hr modules.
Each module adds statistics and links in the kanban vignette, either
in a to do or to approve column.
The department kanban view can be seen as a small dashboard to have
the main data about the department displayed. Links allow the HR
manager to be redirected towards the various things to do or to
approve in its department.
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
Failure to have this dependency means that the drop-down for
HR permissions on the user will always only show Employee
even if the user also has Officer/Manager access
bzr revid: odo@openerp.com-20110824151143-cysnlvetzrvqrfs2
Jeremy Kersten