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
Tyson Phillips (Inactive)
created issue -
Tyson Phillips (Inactive)
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Component/s | Staff Interface [ 10000 ] |
Tyson Phillips (Inactive)
made changes -
Tyson Phillips (Inactive)
made changes -
Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
| Status | Open [ 1 ] | In Progress [ 3 ] |
Automated transition triggered when Jonathan Reissmueller created pull request #439 in Stash -
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Remaining Estimate | 0 minutes [ 0 ] | |
| Time Spent | 15 minutes [ 900 ] | |
| Worklog Id | 11110 [ 11110 ] |
| Assignee | Jonathan Reissmueller [ jonathan ] |
Automated transition triggered when Tyson Phillips (Inactive) merged pull request #439 in Stash -
| Status | In Review [ 5 ] | Closed [ 6 ] |
Tyson Phillips (Inactive)
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
Tyson Phillips (Inactive)
made changes -
| Time Spent | 15 minutes [ 900 ] | 27 minutes [ 1620 ] |
| Worklog Id | 11112 [ 11112 ] |
Tyson Phillips (Inactive)
made changes -
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
Tyson Phillips (Inactive)
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
Tyson Phillips (Inactive)
made changes -
| Description |
A new *Clients.export* 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, *Clients.export*. 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 |
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 |
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.
Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
| Status | Reopened [ 4 ] | In Progress [ 3 ] |
Automated transition triggered when Jonathan Reissmueller created pull request #445 in Stash -
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
Automated transition triggered when Tyson Phillips (Inactive) merged pull request #445 in Stash -
| Status | In Review [ 5 ] | Closed [ 6 ] |
Tyson Phillips (Inactive)
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
Tyson Phillips (Inactive)
made changes -
| Summary | Create new Clients.export event handler | Create new Report.clientData event handler |
Tyson Phillips (Inactive)
made changes -
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
Change the name of this event to "Report.clientData". So, create a new "EventsReportCallback" with a method "clientData".