Getting Started with Issue Management

Blindata, through the Issue Management module, supports a well-structured process for managing issues and reports. The Issue Management module is accessible under the “Management” > “Issues” item of the platform menu, as shown in the figure.

Issues Menu

The section contains two pages:

  • My Work : The page presents the list of all the issues that have been assigned to the current user or to a team to which the user belongs; the page is automatically filtered to show open issues (i.e. all those in a state other than DONE).

    My Work

  • Issues : The page lists all the issues that are present on the platform; the page is automatically filtered to immediately see the open issues (i.e. all those in a state other than DONE). Issue navigation tools are available on the page: it is possible to search for the issue of interest by name using the search box at the top right or filter the issues using the appropriate form. It is also possible to download the CSV file of the filtered issues.

    Issues List

Each record of the “My Work” page and of the registry is interactive. Firstly, it is immediately possible to change the status of an issue using the appropriate drop-down menu. Furthermore, clicking on the record brings to the detail page of the issue.

How to Create and Edit an Issue

Use the FAB button on the “Issues” page to create a new issue. Issue Creation

Then proceed to complete the form that just appeared. Issue Creation Modal

Field Description
Name The name of the issue.
Description A description of the issue.
Type The type of issue. Blindata supports 7 different types of issues, which are:
  • Bug : an anomaly that leads to an unexpected or incorrect result.
  • Vulnerability : indicates compromised, missing, or reduced security measures.
  • Warning : indicates a point to be careful about, which could cause difficulties in the future.
  • Alert : a general warning that may indicate the presence of dirty data or unexpected results.
  • Task : a development activity.
  • Feature Request: a specific development request from a user (e.g., adding a description field in a particular resource).
  • Question: a question from a user.
Each of these types is associated with an icon to give the user immediate visual feedback.
Campaign The campaign to which the issue is associated.
Resource The resource to which the issue is associated.
Severity Indicates the degree of urgency with which the issue is marked. Different levels define this field:
  • Blocker : if the problem is blocking; this is the case with the highest priority.
  • Critical : the problem is very serious but does not block the workflow or other functions.
  • Major : a problem of significant severity.
  • Minor : a non-blocking problem that may need intervention.
  • Info : in this case, it is a request for clarification from a user to a team or another user.
Priority Order Numeric indication of the actual priority level of the issue.
Status Indicates the status of the issue among the 4 possible:
  • To Do
  • In Progress
  • Review
  • Done
Assignee & Team The issue can be assigned to either a user or a team. After the assignment, the responsible parties for the issue will be immediately notified. To assign the issue to a team, the user creating the issue must have reading permissions for the team. The selector only shows the teams on which the user has reading permissions. If a user wants to see all the teams, a Read All policy must be specified in the default team settings for that specific user. If the issue is created through the Blindata Agent, the user of the agent must also have reading permissions for the team.
Reporter Who is reporting the issue. For convenience, Blindata automatically puts the user currently logged in as a reporter, but it is possible to change it.
Estimate This field, exclusively numerical, indicates the estimated effort for solving the problem. It could indicate, for example, the days needed for work.
Planned Start & Due Date The expected dates for the start and end of activities on the issue.

The issue can be completed by additional and custom properties. To edit an issue you need to go to the issue detail page.

Issue Modify

The detail page, in addition to offering cancellation and modification actions, allows you to view all the information related to the issue.

How to create an Issue on a resource

It is also possible to create an issue within a resource using the dedicated widget, which is located on the top right corner of the page.

Issue on a Resource In the case shown in the image, the resource has no issue defined within it. By interacting with the widget, a modal will open in which all the issues on the resource are listed (in this case the list is obviously empty) and from which it will be possible to create a new issue.

Issues on a Resource Modal

Once an issue has been created within the resource, it will immediately be shown in the modal.

Issues on a Resource Modal Full

If the resource has one or more open issues on it, these will be shown in the resource detail page widget as well ( as shown in the following figure ).

Issues on a Resource Widget Full

Moreover, if a resource has dependent resources linked to it and there are issues defined on these latter resources, the “parent” resource in its counting component will also show these issues.

The following example shows that since there is a hierarchical relationship between the “PhysicalEntityDemo” entity and the “PhysicalFieldDemo” field, such that the field belongs to the entity, the widget present in the detail page of the entity shows both the issues directly opened on the entity and the one opened on the field (bug).

Issues on child Resource

Issues and Notifications

The following events trigger notifications (via platform and email):

  • to the issue reporter (if any);
  • to the specific assignee (if any);
  • to all operational members of any team to which the issue has been assigned;

The user who is creating, modifying, or deleting the issue is always excluded from the list of notification recipients.

Types of Notification Description
Creation During the creation of an issue, the notification system aims to alert the following users :
  • Issue reporter
  • Assignee(s) and/or team members
Notification type: ASSIGNED
Edit Based on the modification made, different events will be notified:
  • If the assignee is added/modified or the team to which the issue is assigned is added/modified, the notified event is of type ASSIGNED ( the purpose is to notify the interested users that they have been assigned an issue )
  • If the status is changed:
    • IN_PROGRESSSTARTED
    • REVIEWPUT_ON_REVIEW
    • DONECOMPLETED
    • Status change to TO_DO is not notified.
  • If none of the above conditions are met, the change is notified as MODIFIED
State Transition The type of notification changes based on how the status is modified:
  • IN_PROGRESSSTARTED
  • REVIEWPUT_ON_REVIEW
  • DONECOMPLETED
  • Status change to TO_DO is not notified.
Deletion Following the deletion of an issue, the users who have been identified as the one who reported the issue (reporter) or those to whom the issue has been assigned (assignee and/or team members) are notified through a DELETED notification.