New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] base: Add support for private addresses #24573

Merged
merged 1 commit into from May 4, 2018

Conversation

Projects
None yet
10 participants
@tivisse
Contributor

tivisse commented May 4, 2018

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

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[IMP] base: Add support for private addresses
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
@Yajo

This comment has been minimized.

Contributor

Yajo commented May 4, 2018

It would be nice to have a way to restrict access to contacts more granularity, like i.e. if user is or not a follower for the contact, or if the contact belongs to a sales team where the user is member.

@C3POdoo C3POdoo added the RD label May 4, 2018

@tivisse

This comment has been minimized.

Contributor

tivisse commented May 4, 2018

Hi @Yajo

This could be done by defining a specific ir.rule. This kind of restriction is too specific to be done in a standard release.

@tivisse tivisse merged commit 2f15a5f into odoo:master May 4, 2018

@tivisse tivisse deleted the odoo-dev:master-salary-partner-yti branch May 4, 2018

@yung-wang

This comment has been minimized.

yung-wang commented May 4, 2018

Thanks we need this for our issue:
#18610

Can you also think about the manager employee relationship? For us we need that only the manager can see the private data of his employees. This manager is not allowed to see addresses of other employees.

@dreispt

This comment has been minimized.

Contributor

dreispt commented May 7, 2018

Are there plans to merge this into any stable versions (such as 11.0)?

@tivisse

This comment has been minimized.

Contributor

tivisse commented May 7, 2018

@dreispt

We plan to add the new address type ('private', 'Private') on the Selection field.

@wtaferner

This comment has been minimized.

Contributor

wtaferner commented May 7, 2018

@tivisse
Thank you for taking this step forward. I agree that there should be taken more steps to help Odoo as a software to comply with GDPR easier. But true, the question is what we put into core and what needs to be done by the integrator and foremost the company who is using Odoo as an enterprise software and needs finally to comply (together in responsibility with all its partners)

Sidenote:
Are you aware that this only works for contacts having a parent_id via the GUI? So to be able to mark an individual as private is only possible with a trick (to add a parent, change the type and remove the parent again). Or do I miss something with the approach as implemented by now?

@dreispt
Taking a look at the code does give me the opinion that it could eventually be backported in stable and is needed from a GDPR PoV as we can't wait for a year or more.

@rafaelbn

This comment has been minimized.

rafaelbn commented May 22, 2018

Hi @tivisse do you plan to make a backport to v11?

@tivisse

This comment has been minimized.

Contributor

tivisse commented May 24, 2018

Dear all,

I will backport this commit in 9.0. The work continues on this PR: #24891

@pedrobaeza

This comment has been minimized.

Contributor

pedrobaeza commented May 24, 2018

Bravo!

@jladage

This comment has been minimized.

jladage commented Aug 1, 2018

With the current code when adding new employees (and add a home_address) do get the type private, but all existing records don't.

How would a customer with 300+ employees already added with home_address_id records already created for each employee deal with setting the existing res.partner object to type 'private'? Should he go by all those records and set the type to private? Oh wait you can set the type anywhere ;)

It might be handy to be able to set all res.partners linked to an employee record on the address_home_id to type private. Or do this automatically when updating the module during startup or something.

@emagdalenaC2i

This comment has been minimized.

emagdalenaC2i commented Aug 2, 2018

@jladage I think you can export, change the type to private address and import that contacts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment