Implement personal data consent handling in tickets

[paulo-rossy]

Hello team,

In our country, there is a personal data protection law that prohibits sharing personal information without the user's consent.

Currently, the project does not implement logic to comply with this requirement. Specifically, a service provider should not be able to see personal data in tickets unless the resident has given explicit permission.

Proposal:

• Add a boolean flag isPersonalDataConsentGiven to the Ticket model, indicating whether the resident has granted permission to share their personal data with third parties for incident resolution.
• In the service provider’s profile, display tickets either anonymized or with full information depending on the value of this flag.
• For the open-source version, introduce a configuration parameter PERSONAL_DATA_CONSENT_REQUIRED (default: false). If set to true, the system enforces consent verification logic; if false, it works without additional checks.

I kindly ask you to consider implementing this enhancement.

[tolmachev21]

Hi, @paulo-rossy! Thank you for your issue and interest in the project!

There is also a law on the protection of personal data in our country. However, we have solved this problem in such a way that when registering, the user confirms consent to the processing of personal data and viewing of this information by the service provider.

If you add approximately similar information to the client (frontend), will this cover your needs or not? It seems that this will be the fastest and easiest solution.

However, if this does not meet the requirements of the law in your country, then we will consider the possibility of adding an additional field on the backend.

I would like to clarify your requirements right away: can we add this information to the User (globally) or do you need this information specifically in the ticket? And if you need the second option, then which ticket fields should be hidden on the frontend?

If you have any questions, I will be happy to answer them!)

[paulo-rossy]

Hello @tolmachev21,

Thank you for your prompt response and willingness to discuss this! 🙏

Regarding your question:

1. Global consent vs. per-ticket consent
   In our jurisdiction, consent must be explicitly tied to a specific purpose (GDPR). While global consent during registration covers general data processing, sharing personal data with third-party service providers for each specific incident requires separate granular consent.

   • Example: A resident might agree to general data processing but refuse sharing their phone number with an external contractor for a particular issue.

2. Proposal refinement
   If implementing a per-ticket consent flag is feasible, I suggest:

   • Fields to anonymize when consent is not given:
     resident_name, contact_phone, email, address (any personally identifiable fields in Ticket).
   • Fallback to global consent:
     If PERSONAL_DATA_CONSENT_REQUIRED=false (default), use the existing global user consent as today.

Thank you for your collaboration!

[paulo-rossy]

@tolmachev21, Hello! Is there any news or updates? Do I need to describe the use cases in more detail?

[tolmachev21]

Hi, @paulo-rossy! Sorry for the delayed response, we've discussed your question. It seems we can add a new field to the Ticket model.

However, there are a few questions:

1. Should personal data be stored on the backend? Or should the backend not store personal data for a specific ticket?

In the first case, we can conditionally display fields with personal data only on the frontend. In the second case, we need to finalize the logic for clearing fields with personal data when a resident user creates a ticket.

2. After a resident user creates a ticket, we automatically create a contact with that user's phone number and name. This allows third parties to immediately receive the resident's personal data. Should this logic be removed in your case?

[tolmachev21]

Hi, @paulo-rossy! Is this issue relevant to you? We're willing to correct our logic, but we need to know what behavior you expect