Details
-
Type:
Improvement
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Epic Link:
Description
Use monolog to log activity in an Info log (see RFC 5424) to the database, and display this content in the staff UI.
This would require:
- PHP 5.3+ (i.e. Blesta 4+)
- A custom monolog process to acquire data necessary for logging, based on, or extended from, the bundled 'WebProcessor'
- A custom monolog handler to properly log that data to a MySQL database
- Model for display the log records
- UI for displaying under Logs as well as under the client's profile
log_info
- id (Auto increment ID for the entry)
- company_id (The ID of the company the action was triggered under)
- channel (The channel the action occurred under,. e.g. 'general', but may include 'module', 'gateway', 'plugin', etc. in the future)
- client_id (Client ID that the action relates to, if any)
- user_id (User that performed the action that triggered the log entry)
- user_ip (User's IP address)
- message (A JSON encoded string of message and context data)
- date_added
PK: id
Key: client_id
Key: user_id, company_id
Key: company_id, channel, user_ip
The message of a log would contain JSON encoded data. For example, if a client changes their login password the message might be stored as:
{
"message": "Client #{{id_code}} updated user password.",
"context": {
"id_code": 123,
"id": 20
}
And displayed as: Client #123 updated user password.
Activity
Cody Phillips (Inactive)
created issue -
Cody Phillips (Inactive)
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Security | Private [ 10000 ] |
Cody Phillips (Inactive)
made changes -
| Rank | Ranked higher |
Cody Phillips (Inactive)
made changes -
| Summary | Logging actions of users | Info logging |
Cody Phillips (Inactive)
made changes -
| Description |
We should log activity of users in a rotating log file. We can use monolog's RotatingFileHandler.
This would contain "info" (see [PSR-3|https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md]) records. We would place these files in /configurable/path/to/logs/*activitiy/*. If the content of the file needs to be viewed from within the UI, we would need to record these records in the database, but the actions would have to be explicitly defined (and we would need to implement our own custom handler for such actions). I don't think things like "Name-of-user reset their cPanel password for domain domain.com" makes sense to include, as those are all custom to the module itself. We would need to instead extend the capability of modules to log such activity (i.e. the module would need to have full control over what is or isn't logged). |
Use monolog to log acitivity
We should log activity of users in a rotating log file. We can use monolog's RotatingFileHandler. This would contain "info" (see [PSR-3|https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md]) records. We would place these files in /configurable/path/to/logs/*activitiy/*. If the content of the file needs to be viewed from within the UI, we would need to record these records in the database, but the actions would have to be explicitly defined (and we would need to implement our own custom handler for such actions). I don't think things like "Name-of-user reset their cPanel password for domain domain.com" makes sense to include, as those are all custom to the module itself. We would need to instead extend the capability of modules to log such activity (i.e. the module would need to have full control over what is or isn't logged). |
Cody Phillips (Inactive)
made changes -
| Summary | Info logging | Logging activity in Info log |
Cody Phillips (Inactive)
made changes -
| Description |
Use monolog to log acitivity
We should log activity of users in a rotating log file. We can use monolog's RotatingFileHandler. This would contain "info" (see [PSR-3|https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md]) records. We would place these files in /configurable/path/to/logs/*activitiy/*. If the content of the file needs to be viewed from within the UI, we would need to record these records in the database, but the actions would have to be explicitly defined (and we would need to implement our own custom handler for such actions). I don't think things like "Name-of-user reset their cPanel password for domain domain.com" makes sense to include, as those are all custom to the module itself. We would need to instead extend the capability of modules to log such activity (i.e. the module would need to have full control over what is or isn't logged). |
Use monolog to log activity in an *Info* log (see [RFC 5424|http://tools.ietf.org/html/rfc5424]) to the database, and display this content in the staff UI.
This would require: - PHP 5.3+ (i.e. Blesta 4+) - A custom monolog process to acquire data necessary for logging, based on, or extended from, the bundled 'WebProcessor' - A custom monolog handler to properly log that data to a MySQL database - Model for display the log records - UI for displaying under *Logs* as well as under the client's profile *log_info* - id (Auto increment ID for the entry) - company_id (The ID of the company the action was triggered under) - channel (The channel the action occurred under,. e.g. 'general', but may include 'module', 'gateway', 'plugin', etc. in the future) - client_id (Client ID that the action relates to, if any) - user_id (User that performed the action that triggered the log entry) - user_ip (User's IP address) - message (A JSON encoded string of message and context data) - date_added *PK*: id *Key*: client_id *Key*: user_id, company_id *Key: company_id, channel, user_ip The *message* of a log would contain JSON encoded data. For example, if a client changes their login password the message might be stored as: {noformat} { "message": "Client #{{id_code}} updated user password.", "context": { "id_code": 123, "id": 20 } {noformat} And displayed as: *Client #123 updated user password.* |
Cody Phillips (Inactive)
made changes -
| Description |
Use monolog to log activity in an *Info* log (see [RFC 5424|http://tools.ietf.org/html/rfc5424]) to the database, and display this content in the staff UI.
This would require: - PHP 5.3+ (i.e. Blesta 4+) - A custom monolog process to acquire data necessary for logging, based on, or extended from, the bundled 'WebProcessor' - A custom monolog handler to properly log that data to a MySQL database - Model for display the log records - UI for displaying under *Logs* as well as under the client's profile *log_info* - id (Auto increment ID for the entry) - company_id (The ID of the company the action was triggered under) - channel (The channel the action occurred under,. e.g. 'general', but may include 'module', 'gateway', 'plugin', etc. in the future) - client_id (Client ID that the action relates to, if any) - user_id (User that performed the action that triggered the log entry) - user_ip (User's IP address) - message (A JSON encoded string of message and context data) - date_added *PK*: id *Key*: client_id *Key*: user_id, company_id *Key: company_id, channel, user_ip The *message* of a log would contain JSON encoded data. For example, if a client changes their login password the message might be stored as: {noformat} { "message": "Client #{{id_code}} updated user password.", "context": { "id_code": 123, "id": 20 } {noformat} And displayed as: *Client #123 updated user password.* |
Use monolog to log activity in an *Info* log (see [RFC 5424|http://tools.ietf.org/html/rfc5424]) to the database, and display this content in the staff UI.
This would require: - PHP 5.3+ (i.e. Blesta 4+) - A custom monolog process to acquire data necessary for logging, based on, or extended from, the bundled 'WebProcessor' - A custom monolog handler to properly log that data to a MySQL database - Model for display the log records - UI for displaying under *Logs* as well as under the client's profile *log_info* - id (Auto increment ID for the entry) - company_id (The ID of the company the action was triggered under) - channel (The channel the action occurred under,. e.g. 'general', but may include 'module', 'gateway', 'plugin', etc. in the future) - client_id (Client ID that the action relates to, if any) - user_id (User that performed the action that triggered the log entry) - user_ip (User's IP address) - message (A JSON encoded string of message and context data) - date_added *PK*: id *Key*: client_id *Key*: user_id, company_id *Key*: company_id, channel, user_ip The *message* of a log would contain JSON encoded data. For example, if a client changes their login password the message might be stored as: {noformat} { "message": "Client #{{id_code}} updated user password.", "context": { "id_code": 123, "id": 20 } {noformat} And displayed as: *Client #123 updated user password.* |
Cody Phillips (Inactive)
made changes -
| Epic Link | CORE-1850 [ 12725 ] |