[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: |
|
||||||||
| 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:
|
| 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 ] |
This would fix editing of exiting contacts. |
| 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: 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:
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.
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. |