Details
-
Type:
Sub-task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 4.3.0-b1
-
Component/s: Staff Interface
-
Labels:None
Description
A new Report.clientData event dandler needs to be created to retrieve data from the registered plugins. This is particularly useful for GDPR purposes when Blesta needs to retrieve all client information for export, but is not aware of client data that plugins may be storing. The plugin should register with this event and return any data necessary.
- Add a new Event Handler, Report.clientData. It should be triggered when the client export report is generated
- Each registered plugin should be given the client ID and return back all client-related data in a single object
- Care should be taken to limit memory and processing usage
Issue Links
Activity
There has already been a PR merged which refers to this as 'ReportManager.export.client'. The 'This.that' was a concern for us since the event nomenclature had previously been 'Model.method' and we didn't want to have confusion. Is that no longer a concern with the new event system?
Yes, that naming scheme could conflict when being used for a different purpose, like this task where reports are generated from a component. However, following the report naming scheme, it is easy to create a new report called "client_data" (CORE-2691) that can invoke this event. Since a controller/model would be plural (e.g. "Reports.*") we should be able to avoid conflict should a "Reports" model with events ever be created by using the singular naming scheme "Report." for events on individual reports.
Also, keeping the event name to a single dot separator (i.e. "Class.method") allows the new event listener (CORE-2701) to automatically find the observer callback based on the event name rather than having to specify it directly by full namespace path.
In the future, I envision a set of repository classes that perform actions where models and other services get called whereby the event is invoked from the repository rather than on the model/service.
Tyson Phillips (Inactive)
added a comment - Yes, that naming scheme could conflict when being used for a different purpose, like this task where reports are generated from a component. However, following the report naming scheme, it is easy to create a new report called "client_data" ( CORE-2691 ) that can invoke this event. Since a controller/model would be plural (e.g. "Reports.*") we should be able to avoid conflict should a "Reports" model with events ever be created by using the singular naming scheme "Report." for events on individual reports.
Also, keeping the event name to a single dot separator (i.e. "Class.method") allows the new event listener ( CORE-2701 ) to automatically find the observer callback based on the event name rather than having to specify it directly by full namespace path.
In the future, I envision a set of repository classes that perform actions where models and other services get called whereby the event is invoked from the repository rather than on the model/service. 
Change the name of this event to "Report.clientData". So, create a new "EventsReportCallback" with a method "clientData".