diff --git a/docs/admin-panel/EventMonitoring.mdx b/docs/admin-panel/EventMonitoring.mdx new file mode 100644 index 000000000..b9c63e94d --- /dev/null +++ b/docs/admin-panel/EventMonitoring.mdx @@ -0,0 +1,67 @@ +--- +sidebar_position: 3 +sidebar_label: Event monitoring +--- + +# Event monitoring + +Starting from version 23.2, ReportPortal can monitor all activities (events) at both the project and instance levels. + +## Project level event monitoring + +To view the list of all activities within your project, open the menu at the bottom of the page as an Administrator and select the "Administrate" option. All existing projects are listed on the "All Projects" page. Click on the ellipsis button next to the project and choose the "Monitoring" option from the dropdown. + +Here, you will find a table with the following columns: Time, User, Action, Object Type, Object Name, Old Value, and New Value. + + + +### Time + +This column displays the time in a "time ago" format (e.g., "10 minutes ago"). Hovering over it, the system should show the precise action time. + +### User + +This column shows who acted. We track not only actions by specific users but also, for your convenience, actions performed by ReportPortal itself or certain ReportPortal services. For example, actions by Jobs Service (such as Launch deletions) are included. + +If the activity was on behalf of a user, and their account was deleted, then there will be a "deleted user" entry in the "User" column. + +### Action + +This column displays all events within this project. + +**Event actions:** Create dashboard, Update dashboard, Delete dashboard, Create widget, Update widget, Delete widget, Create filter, Update filter, Delete filter, Create custom defect type, Update defect, Delete defect, Create integration, Update integration, Delete integration, Start launch, Finish launch, Delete launch, Update project, Update analyzer, Post issue, Link issue, Unlink issue, Generate index, Delete index, Start import, Finish import, Update item, AA linked issue, AA changed defect type, Create pattern rule, Update pattern rule, Delete pattern rule, PA find pattern. + +### Object Type + +This refers to the object on which the action was taken. + +**Event objects:** Launch, Dashboard, Custom defect type, Notification rule, Filter, Import, Integration, Test item, Project, Ticket, User, Widget, Pattern Rule, index, Plugin. + +### Object Name + +This is the name of the widget, launch, etc. + +The **Old Value** and **New Value** columns display the changes that were made. + +You can filter activities by user, action, object type, and object name. + + + +Another way to view the event list in your project is by creating a ["Project Activity Panel" widget](/dashboards-and-widgets/ProjectActivityPanel). + +## Instance level event monitoring + +Instance level events are not displayed in the UI – they are stored in the database. + +**Instance level events:** Account deletion, Bulk account deletion, Administrator unassign, Provide Administrator permission for a user, Project creation, Bulk delete project by ReportPortal administrator, Delete project by ReportPortal administrator, Delete project by ReportPortal administrator, Delete Personal project when deleting user, Create Global Integration, Update Global Integration, Delete Global Integration, Bulk delete of Global Integration via API only, Manual plugin upload, Delete Plugin, Update Plugin (disable/enable), Create user in Administrate, Create user via auth service SAML. + +Additionally, during instance setup, you can enable event storage in an audit log file. This data can be sent to a Security Information and Event Management (SIEM) system using tools like Fluentd, Fluentbit, or Filebeat. Logs and events are then checked and monitored within the SIEM system. + +The primary advantage of the audit log file is that it preserves all records without alterations or deletions. In contrast, data in the database can be modified or deleted. For example, if launches or projects are deleted, the corresponding data is removed from the database. Deleting accounts leads to data obfuscation in the database. + +Hence, if historical monitoring and strict accountability are required, enabling event storage in an audit log file is recommended. Financial companies, for example, are often mandated to retain all user actions in their services for 3 years. + +:::note +Administrators should ensure that log rotation is configured for the location where the audit log will be saved, as a substantial amount of data will accumulate. +::: +Event monitoring assists organizations, especially in industries like finance and healthcare, in maintaining the security of their systems and data. diff --git a/docs/admin-panel/img/EventMonitoring.png b/docs/admin-panel/img/EventMonitoring.png new file mode 100644 index 000000000..0622a8122 Binary files /dev/null and b/docs/admin-panel/img/EventMonitoring.png differ diff --git a/docs/dashboards-and-widgets/ProjectActivityPanel.mdx b/docs/dashboards-and-widgets/ProjectActivityPanel.mdx index 0b4196ea1..a4028eaee 100644 --- a/docs/dashboards-and-widgets/ProjectActivityPanel.mdx +++ b/docs/dashboards-and-widgets/ProjectActivityPanel.mdx @@ -9,17 +9,19 @@ The widget shows all activities occurring on the project. **Widget's parameters:** -- The actions for the widget are as follows: Update Project Settings, Update Defect Types, Delete Launch, Start Launch, Finish Launch, Share Widget, Dashboard, Unshare Widget, Dashboard, Post Issue to BTS, Add, Register User, Update BTS. By default, all actions are checked. +- **The actions for the widget:** Start launch, Finish launch, Delete launch, Actions with issues, Assign/Invite users, Unassign user, Change role, Update Dashboard, Update widget, Update Filter, Update integration, Update project settings, Update Auto-Analysis settings, Update defect types, Import, Update Pattern-Analysis settings, Create pattern, Update pattern, Delete pattern, Pattern matched, Create project. -- Items: 1-150. The default meaning is 50. +- **Items:** 1-150. The default value is 50. -- Type user name: By default all user's activities. +- **Criteria for widget:** By default, all user's activities. **Widget view** The actions on the widget are present in a table, separated by days. Action messages have the following format: > *Member (name) did action.* -> *Time - displayed in 'time ago' format (i.e. "10 minutes ago"). On mouse hover, the system should display accurate action time.)* +> *Time - displayed in 'time ago' format (i.e. "10 minutes ago"). On mouse hover, the system should display accurate action time.* + + diff --git a/docs/dashboards-and-widgets/img/widget-types/ProjectActivityPanel.png b/docs/dashboards-and-widgets/img/widget-types/ProjectActivityPanel.png index e5e70a518..bacb5beb9 100644 Binary files a/docs/dashboards-and-widgets/img/widget-types/ProjectActivityPanel.png and b/docs/dashboards-and-widgets/img/widget-types/ProjectActivityPanel.png differ diff --git a/docs/user-account/DataRetentionProcedure.md b/docs/user-account/DataRetentionProcedure.md new file mode 100644 index 000000000..9b2b2e1dc --- /dev/null +++ b/docs/user-account/DataRetentionProcedure.md @@ -0,0 +1,56 @@ +--- +sidebar_position: 4 +sidebar_label: Data retention procedure +--- + +# Data retention procedure + +Starting from version 23.2, ReportPortal introduces an option to establish a retention period for collected Personally Identifiable Information (PII) data during instance configuration. This configuration allows for setting an individual retention duration for the instance in days, such as N=90, 180, 540 or any other number of days. + +**Docker** + +To activate data retention, add the following environment variables to Service Jobs: + +``` +# Int (days) +RP_ENVIRONMENT_VARIABLE_CLEAN_EXPIREDUSER_RETENTIONPERIOD: + +# CRON +RP_ENVIRONMENT_VARIABLE_CLEAN_EXPIREDUSER_CRON: +RP_ENVIRONMENT_VARIABLE_NOTIFICATION_EXPIREDUSER_CRON: +``` + +**Kubernetes** + +Fill in Service Jobs values in the [values.yaml](https://github.com/reportportal/kubernetes/blob/master/reportportal/values.yaml) + +``` +servicejobs: +coreJobs: + # Int (days) + notifyExpiredUserCron: + + # CRON + cleanExpiredUserCron: + cleanExpiredUserRetention: +``` + +If the data retention option is enabled but a specific number of days for deleting inactive users is not specified, no deletions will occur. In the case of specifying 0 or a negative value, an error will be displayed in the logs. + +When the data retention option is activated, the job will run daily to identify inactive users and obfuscate their data. + +Inactive users are defined as follows: + +1. Users who have not logged in for N days. + +2. Users who have not reported testing data for N days. + +Users are only classified as inactive if both conditions are satisfied. + +In cases where a user logs in but doesn’t submit any reports, they are not deleted as the second condition isn’t fulfilled. Similarly, if a user has not logged in but has submitted reports, they are still considered active. + +Before performing deletions, the system sends out email notifications as follows: notification №1 is dispatched to inactive users N-60 days before deletion, notification №2 is sent N-30 days prior, and notification №3 is sent 1 day before obfuscation. Notifications about account deletion are also sent by the system. + +Users will be able to return whenever they are invited to the project. + +In summary, a data retention policy optimizes resources and helps create a more efficient, secure, and effective environment for data management, which fosters business success. diff --git a/docs/user-account/DeleteAccount.mdx b/docs/user-account/DeleteAccount.mdx new file mode 100644 index 000000000..2b914788e --- /dev/null +++ b/docs/user-account/DeleteAccount.mdx @@ -0,0 +1,26 @@ +--- +sidebar_position: 3 +sidebar_label: Delete account +--- + +# Delete account + +Starting from version 23.2, ReportPortal users can delete their accounts along with their personal data. + +During the instance setup, the DevOps engineer (or whoever is deploying the instance) can use a variable to decide whether the "Delete account" button will appear in each user's profile or not. This setting is specific to each instance. + +``` +RP_ENVIRONMENT_VARIABLE_ALLOW_DELETE_ACCOUNT: true +``` + +When a user clicks on the **"Delete account" button**, a modal window with feedback options appears. The user can select from predefined options or choose "Other" and provide a specific reason for deleting their account. Alternatively, they can simply select "Other" without leaving any comments. + + + +To prevent accidental deletions, the user must enter "Delete" in capital letters to confirm their intention to delete the account. This extra step ensures that the user genuinely wants to proceed with the account deletion. Once the user clicks the "Delete" button, all personal information related to their account, including account name, email, and photo, will be removed from our test automation reporting platform. However, any data created or reported by the user in ReportPortal, such as launches, filters, widgets, and dashboards, will still be retained in the application but will no longer be accessible to the user. Additionally, the user will receive an email notification confirming the account deletion. + + + +In summary, allowing users to delete their accounts and personal data from our automated testing tool is a critical measure to protect user privacy. ReportPortal is committed to adhering to data protection regulations and staying up to date with industry trends to ensure compliance. + + diff --git a/docs/user-account/img/DeleteAccount1.png b/docs/user-account/img/DeleteAccount1.png new file mode 100644 index 000000000..783c3841a Binary files /dev/null and b/docs/user-account/img/DeleteAccount1.png differ diff --git a/docs/user-account/img/DeleteAccount2.png b/docs/user-account/img/DeleteAccount2.png new file mode 100644 index 000000000..f551cc0b6 Binary files /dev/null and b/docs/user-account/img/DeleteAccount2.png differ