georgringer / gdpr Goto Github PK

• hidden, ...
• eye icon
• label

Add composer check for 8.7

Related to #2

In the paid version there are two Command registered (see Configuration/Commands.php), but the PHP files are not there.

This actually breaks everything in a TYPO3 installation with CLI
a) you cannot add any more scheduler tasks based on symfony/console as the commands are not found
b) helhum/typo3-console does not work anymore, as it scans all available commands

make it possible to have that as phar file to support regular ext install

Ask users for consent before loading youtube iframes

See for core issue https://forge.typo3.org/issues/84843

Hello,
would it be possible to completely delete files or content after a certain time, including any referencene? (not only set deleted = 1)

Thank you.

The realurl administration module uses edit as a GET parameter when e.g. editing a pathcache. The key in this case is an integer.

The ButtonBarHook of gdpr takes this integer from the GET parameter and passes it to TableInformation::isTableEnabled which expects a string and therefore a type error Exception is thrown.

Most simple solution: cast the value retrieved from GET to a string before passing it on.

Let's find how we could implement "Forget me" feature (one of the most important points of GDPR).

What it could be :

• Creation of transversal layer in all TYPO3 system, where all contents and data, related to the FE user are tracked via, for example, "feuser_private_data_mm" relations, where any FE user generated content could be tracked;
• Backend module for controlling all these records by admins;
• Mechanism of safe deletion request, which will safely remove those data and contents.

Ressources:

• https://gdpr-info.eu/art-17-gdpr/
• https://techblog.bozho.net/gdpr-practical-guide-developers/

There is a fatal error due to the RestrictionInterface, which does not match the one from TYPO3 Core.

we had to clone this repository in our own mirror and branch it in order to proper branching and tagging. Tagging version 1.0.0 would surely help.

Let's implement "Personal data portability" feature (it's also one of the most important points of European GDPR).

Objective

• On the request of the user it's private information should be exported in a structured, commonly used and machine-readable format

How it could work

• Each frontend user should be able to request records, which contains it's own private data (via FE plugin)
• On the data level, TCA should be extended to classify selected tables / fields with "private data" of the FE user
• Data export API, for private data (but filtering from system information, to avoid additional information disclosure)
• An additional Backend module for the DPO could be added to control if all private data is exportable

Ressources

• https://gdpr-info.eu/art-20-gdpr/
• https://techblog.bozho.net/gdpr-practical-guide-developers/

I would like to propose to implement "Restrict processing" feature (it's also one of the most important points of GDPR).

Objective :

• On the request of the user it's private information should not be available for webmasters in backend, to site visitors in frontend, and should not be exported via TYPO3 backend (CSV) etc.

How it could work :

• Each frontend user should be able to restrict the access to it's own data
• Extend TCA to classify selected tables / fields as "private data" sensible
• Hide sensible columns in the Backend from webmasters
• Extend permission system
• Hide sensible columns in the Frontend from internautes
• Extend frontend rendering system
• Extend data access API, adding additional conditions, where privacy protected fields will be empty, when exported

Ressources:

https://gdpr-info.eu/art-18-gdpr/
https://techblog.bozho.net/gdpr-practical-guide-developers/