[MGNLPRIV-35] Visitor field on Edit contact form shouldn't be required Created: 21/Jun/18  Updated: 22/Jun/18  Resolved: 22/Jun/18

Status: Closed
Project: Privacy
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Neutral
Reporter: Antonín Juran Assignee: Evzen Fochr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLPRIV-37 Reference to visitor added to manuall... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:
Sprint: Kromeriz 152
Story Points: 1

 Description   

Isn't possible to add/edit contact in contact app without setting visitor field.

Resolution:
Required on visitorId field is disabled.
Nodetype removed fro privacy-sample/decorations/contacts/apps/contacts.subApps.detail.yaml decoration

  • old contacts can be created, edited and re-saved without any problem
  • nodetype removal cause not working dependencies check (dependency is not shown) in visitor app if we add visitor to manually created contact.


 Comments   
Comment by Evzen Fochr [ 21/Jun/18 ]

mgnl-nodetypes/magnolia-privacy-nodetypes.xml mandatory needs to be set to false if it should work.

Comment by Roman Kovařík [ 22/Jun/18 ]

rkovarik The idea was: If someone is editing/creating contact, he should assign a visitor (as per GDPR requirements).

ajuran: Existing contacts don't have a visitor. It's possible to create a visitor only via contact form.

rkovarik: We could create an action to create a visitor from the visitors app (as now we need only an email as the ID). Now sure if this can wait for a next version (the required visitor field in the contact app is brought "only" by the privacy sample module).
 
 

 

Comment by Jan Haderka [ 22/Jun/18 ]

rkovarik it would be ok to wait IMO as long as we make this field non-mandatory for now. IF we need to keep it mandatory than we should be able to create visitor directly when creating contact (we have email address at that time too). WDYT?

Comment by Roman Kovařík [ 22/Jun/18 ]

make this field non-mandatory for now

This would fix editing of exiting contacts.
Saving of new contact would probably fail without an visitor ID as it is mandatory property of the node type (should be tested, not sure what the select field saves, maybe an empty visitorId?).
Anyway, depending how it behaves for new contacts, this could be easy workaround.

Comment by Roman Kovařík [ 22/Jun/18 ]

efochr: mgnl-nodetypes/magnolia-privacy-nodetypes.xml mandatory needs to be set to false if it should work.
rkovarik: This is the crucial part of the whole GDPR effort, personal information has to be linked to a visitor.
efochr: there is no visitor on the author instance

rkovarik: the visitor workspace should be clustered.

Comment by Karel de Witte [ 22/Jun/18 ]

For comments, known public user id's are registered now in a private field in the comment if you use the session aware comment api.

For a general use case indeed, a  simple persistent cache for storing anonymous user id's with a ttl mapped to the cookie session id would be a solution i see.

For a complete SSO solution with User Directory and Federation services, I believe AWS cognito provides everything needed and is not too expensive.

 

Comment by Jan Haderka [ 22/Jun/18 ]

Thanks, what i was actually saying is that we might need a place to store visitor data and connect them to personal info about said visitor in magnolia and that we might want/need to store that data somewhere accessible from both public and author instance.

Didn't need any info about how to track visitor, but thanks for that bit anyway

Comment by Evzen Fochr [ 22/Jun/18 ]

Release notes: should be added to known issues - https://jira.magnolia-cms.com/browse/CNTCTSAPP-104

Comment by Antti Hietala [ 22/Jun/18 ]

Roman said:

This is the crucial part of the whole GDPR effort, personal information has to be linked to a visitor.

Correct. However, our clients are unlikely to store personal data of visitors in Magnolia. Magnolia is typically just a mechanism to collect leads. The personal data is almost always pushed out of Magnolia and stored in a system like Watson.

It is important for the Watson user to see if they are allowed to send email to a particular visitor (via a flag such "consent given"). It is not critical that a Magnolia user in the Contacts app cannot edit (process) data. That is too strong interpretation of what processing means.

We should allow adding and editing of Contacts without a visitor link. Doing the opposite would cripple the Contacts app for clients that use it for internal phone books, employees directories etc.

Comment by Roman Kovařík [ 22/Jun/18 ]

The problem is in the sample (decorated contact app) itself, there is no need to touch the privacy API.

We've discussed with Evzen possible solution which is just about changing the decoration of the contact app.

We should allow adding and editing of Contacts without a visitor link. Doing the opposite would cripple the Contacts app for clients that use it for internal phone books, employees directories etc.

They probably shouldn't have samples in the production environment, so they would not be affected.

Comment by Evzen Fochr [ 22/Jun/18 ]

Only issue we will have after this change is if we add visitor to manually created contact, dependency check in visitor app won't show it, but I think we can live with it.

Generated at Mon Feb 12 10:31:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.