Backport of odoo/odoo#81474
Before odoo/odoo#86889 a regular user with employees in multiple
companies was not able to change his own language due to a chain of
event calling onchange on all the employee_ids and employee_ids on
res.users being read as sudo.
The fix does work but was wrong because it gave access to the user's
public employee regardless of the active company_id
A domain was added to employee_ids to make force the security rules even
in sudo.
closesodoo/odoo#94618
X-original-commit: 90cec4073e065c142043fcea1d68a10c7cb72e73
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*:
approvals
hr_apprasaisal
hr_payroll
hr_referral
fleet
hr
hr_attendance
hr_holidays
hr_recruitment
lunch
Change various access rights names to improve understandability for users.
Addition of an officer role in fleet with intermediate accesses
TaskID 2742855
closesodoo/odoo#87545
Related: odoo/enterprise#25741
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce
============
- Connect with Mitchell Admin
- Go to Employee -> Settings and uncheck "Skills Management"
- Go to Settings -> Users, create a user "Test" and give him access to 2 companies (e.g. My Company [San Fransisco] and My Company [Chicago])
- Set current company to My Company [San Fransisco], go to Employees, create an employee record and associate it with your test user (in HR Settings tab)
- Set current company to My Company [Chicago] and create another employee and associate it with your test user too
- Connect as "test" user and go to my profile
- Try to change your langage (From English US to French) ==> Access rights error
Purpose
=======
When the `OnChange` is triggred we try to read the two employees linked to this user, but one of this employees is in unslected company
which leads to Access rights error.
Specification
=============
To solve the issue the domain in the security rule **Employee multi company rule** has been updated, where we added the condition
`('user_id', '=', user.id)` which gives the user the ability to read the needed data.
opw-2793123
closesodoo/odoo#87244
X-original-commit: 5916e15f6fa29fd89e12472b316475e757001945
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In a multi-company environment, it is not possible to update information (language, email,...) from My Profile.
The security rule only allows to change information if the right company is selected or if the user has no company.
Since a user assigned to several companies will have several records in hr_employee referring the same user_id, the security rule is now updated to allow updating information from the My Profile page if the hr_employee.user_id refers to the current user_id.
task-2678411
closesodoo/odoo#80637
X-original-commit: 3e9393c71ccf1b00c051155afd68b3a0cfff05cd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It was possible to assign a user that was not part of the same company
as the employee's for an activity which is misleading.
Make hr.plan and hr.plan.activity.type company dependent.
closesodoo/odoo#77524
Related: odoo/upgrade#2879
Taskid: 2658773
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Automate activites linked to plan on certain triggers.
To automate onboarding and offboarding processes, we can now define
plans that will activate upon triggers, such as employee creation,
departure (archive), contract start or contract end.
Manual plans are still possible.
Upon activation of a plan, a message will be added to the employee's
chatter with the name of the plan.
More options have been added related to when to schedule the plan's
activities.
The blocking mechanism has been removed (the plan would not launch if an
activity could not be started, due to lack of information), failed
activities will now be logged into the employee's chatter.
The list and kanban employee views have also been updated to include
info such as first contract date and activity information.
Task ID: 2489095
closesodoo/odoo#68451
Related: odoo/enterprise#17343
Related: odoo/upgrade#2314
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
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
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
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)
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
William Braeckman