Display Issue Types in Node UIs

[LaraMerdol]

Show issue types in node UIs and enable special filtering for them. Choose appropriate badges for that.

[LaraMerdol]

Jira standart issue types are;

Jira Work Management business projects issue types By default, business projects come with one standard issue type:

• Task:A task represents work that needs to be done. By default, business projects come with one child issue type:
• Subtask: A subtask is a piece of work that is required to complete a task.

Jira software projects issue types By default, software projects come with one parent issue type:

• Epic: A big user story that needs to be broken down. Epics group together bugs, stories, and tasks to show the progress of a larger initiative. In agile development, epics usually represent a significant deliverable, such as a new feature or experience in the software your team develops.

By default, software projects come with three standard issue types:

• Bug: A bug is a problem that impairs or prevents the functions of a product.
• Story : A user story is the smallest unit of work that needs to be done.
• Task: A task represents work that needs to be done.

By default, software projects come with one child issue type:

• Subtask: A subtask is a piece of work that is required to complete a task. Subtasks issues can be used to break down any of your standard issues in Jira (bugs, stories or tasks).

Jira Service Management (service projects) issue types

• Change: Requesting a change in the current IT profile.
• IT help: Requesting help for an IT related problem.
• Incident: Reporting an incident or IT service outage.
• New feature: Requesting new capability or software feature.
• Problem: Investigating and reporting the root cause of multiple incidents.
• Service request: Requesting help from an internal or customer service team.
• Service request with approval: Requesting help that requires a manager or board approval.
• Support: Requesting help for customer support issues.

[LaraMerdol]

As a SAA design for software projects, we are going to use the following issue types and hierarchy. We have also decided to use Jira issue type icons to be consistent with Jira.Jira.

• Epic: A big user story that needs to be broken down. Epics group together bugs, stories, and tasks to show the progress of a larger initiative. In agile development, epics usually represent a significant deliverable, such as a new feature or experience in the software your team develops.

• Bug: A bug is a problem that impairs or prevents the functions of a product.

• Story : A user story is the smallest unit of work that needs to be done.

• Task: A task represents work that needs to be done.

• Subtask: A subtask is a piece of work that is required to complete a task. Subtasks issues can be used to break down any of your standard issues in Jira (bugs, stories or tasks).

[LaraMerdol]

[LaraMerdol]

We also include issue types for Improvement and New Feature. A list of added issue types and their respective icons can be found below.

= Epic = Bug = Story = Task = Sub-task = Improvement = New-feature = other (custom issue types or others)

[LaraMerdol]

[LaraMerdol]

For issues with issue type other than selected ones ;

[LaraMerdol]

Are we allowed to use Jira icons for node types? Check any license terms.

[ugurdogrusoz]

I think this looks great. Let's try moving both the issue type and the priority badges toward the outside of the node icon, barely touching the issue icon.

[ugurdogrusoz]

Let's also make sure that these badges (same with priority badges) are persistent and do not go away when the user removes highlights!

[LaraMerdol]

's also make sure that these badges (same with priority badges) are persistent and do not go away when the user removes highlights!

Fix the issue so that the proprietary badges and the typed badges do not disappear when cues are removed.

[ugurdogrusoz]

Let's also make sure that these badges (same with priority badges) are persistent and do not go away when the user removes highlights!

Only those badges (issue priority and type) that should be persistent should stay on remove highlights, not regular highlighting, not badges added by other facilities such as graph theoretic property metrics.

[LaraMerdol]

The style of the issued badges will be updated according to the comment.

[ugurdogrusoz]

The badges look great, thank you! Some issues:

• [x] 1. Now all badges and resizes, etc. are persistent on Remove Highlights. Normally, when we calculate a graph theoretic property and resize a node and put a badge and then apply Remove Highlights, things would go back to normal. We still want this except issue type and priority badges being persistent.

• [x] 2. This is probably a depth issue, even though context menus will overwrite node badges as well as nodes/edges, they do not overwrite issue type and priority badges:

  

• [x] 3. When graph theoretic properties are applied and node sizes are adjusted, badges get shifted as below (they do correct on a redraw though - e.g. on panning):

• [x] 4. The two badges are somehow not aligned exactly:

  

• [ ] 5. Since anomaly and graph theoretic property badges will overlap, when one is in use, the other should be removed (both ways).

• [ ] 6. Some graph-theoretic property calculation operations have no effect (no badges displayed). In fact, these also break the type and property badges of issues (i.e., (Normalized) Inter-Group Centrality and Pull requests: Change line of code). Let's also make capitalization consistent here: Pull Requests: Change Line of Code

[LaraMerdol]

Fix subtask 3 align badges;

[LaraMerdol]

Fix subtask-3:

Change the addIssueBadges() function to take a size parameter addIssueBages (size: number = 18), with the default value of 18, which is a 0.5625 ratio with the issue node size (18/32). When adding badges, after calculating theoretical properties and adjusting node size, add issue type and priority badges according to the node's new size, while keeping the 0.5625 ratio.

[LaraMerdol]

Fix subtask 2: The badges are not aligned at the top of the context menu and their z-index has been reduced.

[LaraMerdol]

1. Now all badges and resizes, etc. are persistent on Remove Highlights. Normally, when we calculate a graph theoretic property and resize a node and put a badge and then apply Remove Highlights, things would go back to normal. We still want this except issue type and priority badges being persistent.

Could you clarify subtask-1 a little more? I'm not sure if it's related to resizing the issue badges after calculating theoretical properties or something else. @ugurdogrusoz

[LaraMerdol]

Also, I suggest removing anomaly badges when calculating theoretical properties because in that case, anomaly badges and theoretical property badges overlap, both appearing in the top right corner. Users can add later if they want to see them.

[ugurdogrusoz]

1. Now all badges and resizes, etc. are persistent on Remove Highlights. Normally, when we calculate a graph theoretic property and resize a node and put a badge and then apply Remove Highlights, things would go back to normal. We still want this except issue type and priority badges being persistent.

Could you clarify subtask-1 a little more? I'm not sure if it's related to resizing the issue badges after calculating theoretical properties or something else. @ugurdogrusoz

Here the confusion comes from the fact that we use badges (temporary annotations on nodes) to show the type and priority of an issue. Normally the badges are used for temporary annotations (e.g., anomaly counts and graph-theoretic property metrics). Hence, "Remove Highlights" should remove all temporary annotations including anomaly counts, graph-theoretic property metrics and should resize the node back to its normal size. The only thing that this operation shouldn't reverse is the type and priority badge of an issue since this is a permanent thing.

[LaraMerdol]

Fix subtask-1: Remove highlights, remove badges, and reset node size to original without affecting constant issue type and priority badges.

[ugurdogrusoz]

Added new items (5 & 6)

[LaraMerdol]

Fix subtask 6:S Anomalous behavior related to some graph-theoretic property calculation operations has no effect (no badges displayed) has been fiexed fixed.

[LaraMerdol]

Fix subtask 6: naming change

[LaraMerdol]

Fix sub-task 5 (Partially): Now, when graph theoretical properties are added, anomaly badges disappear. The problem is that vice versa can not be implemented. The issue is related to graph-theoretical properties. It seems that the problem arises from the fact that the theoretical properties component is designed as a component rather than a service (so removing the poper elements outside the component cannot be managed). I have tried making changes and attempting different solutions, but so far, I have been unable to resolve the issue. One suggestion I have received is to remove all highlight elements when adding anomaly badges. This will also remove the highlights.

[ugurdogrusoz]

5. How about moving one of the overlapping badges to a different location on the node? Middle right or bottom right?
6. "Pull Requests: Change Line of Code": are we talking about changed lines of code here? If so, let's rename it as "Pull Requests: Changed Lines of Code"

[LaraMerdol]

Subtask 6 fixed: Changed according to the feedback.

Subtask 5 fixed: Now, if the theoretical property badge and anomaly detection badges are clicked, the anomaly badge will appear in the right corner. Additionally, the anomaly badge size will change to match the issue node size. If the anomaly badge is clicked, the theoretical properties anomaly badges swap to the right position, and the size is updated to be scaled with the new anomaly size.

[ugurdogrusoz]

This issue is clutter. I am closing this and opening a new one with any remaining problems.