OCA / data-protection

Data Protection
https://github.com/OCA/data-protection/wiki
GNU Affero General Public License v3.0
31 stars 68 forks source link

[10.0][IMP] privacy_consent: Add full manual + dates #40

Closed rousseldenis closed 4 years ago

rousseldenis commented 4 years ago

Adds a full manual mode for more flexibility Adds accepted and refusal dates as info is not easily accessible as in chatter

yajo commented 4 years ago

I don't seem to find a use case where fully manual is better than manual... :thinking: Could you elaborate on that please?

rousseldenis commented 4 years ago

I don't seem to find a use case where fully manual is better than manual... Could you elaborate on that please?

Yes, we could use 'just' the existing manual one. As I didn't want to break the existing behaviour (with action button to switch between states, I've added one more.

But if you think the existing behaviour can be changed, I delete it and just let the buttons in this PR.

yajo commented 4 years ago

AFAICS the only thing you need is to set the Subject field as editable when in manual mode (at least when creating); the rest should be achievable.

rousseldenis commented 4 years ago

AFAICS the only thing you need is to set the Subject field as editable when in manual mode (at least when creating); the rest should be achievable.

  • Wanna set manually as asked? Just hit Ask and send the email. I don't think there's any usefulness in having a consent without a communication history. That would just provide an easy path towards legal unsafety to users which I'd prefer to avoid TBH.

Our business requirement is to allow using data model and structure and feed them with another manner than the mail/controller. See: https://github.com/shopinvader/odoo-shopinvader/pull/566

These modifications allow that.

I agree with buttons behaviour. That should be avoided.

yajo commented 4 years ago

Hmm I don't quite understand that PR you link, it has no description.

Could you please explain what's the workflow you're trying to achieve? Some mockups would help...

rousseldenis commented 4 years ago

Hmm I don't quite understand that PR you link, it has no description.

Could you please explain what's the workflow you're trying to achieve? Some mockups would help...

There are too much things I don't need in this due to misunderstanding of how it works.

The only things I need are the dates in fact. I will modify it

rousseldenis commented 4 years ago

Hmm I don't quite understand that PR you link, it has no description.

Could you please explain what's the workflow you're trying to achieve? Some mockups would help...

I tried to improve this according to this :

What do you think ?

rousseldenis commented 4 years ago

@Cedric-Pigeon What do you think about? Do we really need manual buttons to accept/deny?

yajo commented 4 years ago
  • In some cases, you can have people calling you in support to accept privacy or deny it, you need a way to manage it (with some access rights). But this is not really mandatory.

Yes, you have the "Accepted" checkbox, as mentioned in https://github.com/OCA/data-protection/pull/40#issuecomment-580670372:

2020-03-20_10-29

  • In some flows, you could want to access methods to manipulates this. e.g.: in our case, another web service. At least, we could make these methods for state changing private with '_'.

You have 2 options here:

  1. Call .write({'accepted': boolean_answer})
  2. Call .action_answer(boolean_answer, optional_metadata_str): https://github.com/OCA/data-protection/blob/8247e0e58d3d58fef3407bb42ed6ebc891b97ec4/privacy_consent/models/privacy_consent.py#L174-L187

Again, I don't see a need for this PR, sorry. :man_shrugging: It seems you have to investigate its API and functionality a little bit more, because there's still no use case you can't achieve...

Sorry to close this, please reopen if needed.