[MGNLPRIV-41] Consistent data privacy across multiple instances Created: 26/Jun/18  Updated: 30/Jan/23  Resolved: 30/Jan/23

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

Type: Story Priority: Neutral
Reporter: Antti Hietala Assignee: Unassigned
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by DOCU-1556 Document that GDPR features require s... 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)
Date of First Response:
Epic Link: Data privacy 1
Team: AdminX

 Description   

Implement a solution to keep visitors and their personal data in sync across multiple public instances.

User stories:

As a Data Protection Office, I want a single convenient place to see who my visitors are and where their data resides. (Issue: different visitors are stored on different public instances and I lose oversight.)

As a Visitor, I want the site to remember my consent from one visit to the next. (Issue: A visitor may be stored on different public instances, with different consent info on each.)

As a Visitor, when I change my consent, the site should remember my choice. (Issue: A change of consent on one public instance is not reflected on another public instance.)

As a Visitor, when I request my data to be erased, I want it erased everywhere. (Issue: Data erased from one public instance may still exist on another public instance.)

Acceptance criteria:

  • Personal data is recorded and changed consistently in a multi-instance setup.
  • The visitor's experience is consistent over time regardless of which public instance they hit in a multi-instance setup.

 



 Comments   
Comment by Christoph Meier [ 28/Jun/18 ]

If the synchronizing is "too slow" - the opt-in link (which was sent by email) to grant consent may fail, if the request sent by clicking the email-link goes to "the other public node".

Comment by Christoph Meier [ 28/Jun/18 ]

Probably only slightly related to this ticket - but I add it here too- since it was discussed on a related doc page (https://goo.gl/iV5Wxn)

Manual editing of visitor data with the visitors app must be done on the public context.
On cloud we try to avoid uadmin usage on public context, the cockpit also is not providing a link to public uadmin.

nbarbe:

We try to remove the needs to access the public instances and we have good reasons for that.


(Side note: "Same problem" we have with PUR module.)

Comment by Matt Rajkovic [ 30/Jan/23 ]

Very old issue. Closing.

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