Create new UI for bug reporting phase that allows deleting and un-deleting of issues

[yucongkoo]

Is your feature request related to a problem? Please describe.
Currently, the UI for bug reporting phase only supports creating new issue and deleting issues, we need a UI that can also un-delete issues

Describe the solution you'd like
We should update the UI to have 2 tables, where the top table will show the list of open issues, and the bottom table will show the list of deleted issues, users can then click the delete icon on issues in the top table to delete the open issues, and click the restore icon (new icon) on the bottom table to un-delete the issue.

[yucongkoo]

User related workflows decisions to be made:

1. Currently when users click on the delete icon, there will be a dialog pop-up prompting confirmation as follows

My question: Clearly this action will become reversible under the new design (where users can see a table of deleted issues and restore them during bug-reporting and bug-trimming phase), do we still keep this confirmation dialog? Personally I think I would prefer to just remove this confirmation dialog (since the action is no longer with heavy consequences and users can easily restore the deleted issues)

2. Currently after the users confirm deletion of the issue, there will be a snackBar pop up that allows user to undo the deletion as follows:

My question: Do we still need this snacker?

Some Design details

1. UI

2. View issue page for deleted issues, note that as the permission for users are granted to edit/delete/create issues during this phase, this page is totally same as the original view issue page (i.e. users can still edit deleted issues)

[damithc]

Good points, @yucongkoo

1. Currently when users click on the delete icon, there will be a dialog pop-up prompting confirmation as follows

My question: Clearly this action will become reversible under the new design (where users can see a table of deleted issues and restore them during bug-reporting and bug-trimming phase), do we still keep this confirmation dialog? Personally I think I would prefer to just remove this confirmation dialog (since the action is no longer with heavy consequences and users can easily restore the deleted issues)

Yes, can remove.

3. Currently after the users confirm deletion of the issue, there will be a snackBar pop up that allows user to undo the deletion as follows:

My question: Do we still need this snacker?

No harm keeping it right? It allows a way to quickly recover from a delete-by-mistake case.

2. View issue page for deleted issues, note that as the permission for users are granted to edit/delete/create issues during this phase, this page is totally same as the original view issue page (i.e. users can still edit deleted issues)

I'm wondering if we should do something to make the 2nd table look slightly different (and less prominent) than the first table. E.g., strike-through the issue title, use grey colour for the table heading etc.

[Eclipse-Dominator]

View issue page for deleted issues, note that as the permission for users are granted to edit/delete/create issues during this phase, this page is totally same as the original view issue page (i.e. users can still edit deleted issues)

Just remove the edit buttons or disable them should do this so keeping the page is good enough.
This effectively removes all access to edit/delete/create issues, thus, "restricting" access by disabling these functionalities in the UI.
Teams should also be able to set duplicates issues here as well.

Might be worth considering if this should be turned into a new component or just add a phase check / @Input to the component

---

I'm wondering if we should do something to make the 2nd table look slightly different (and less prominent) than the first table. E.g., strike-through the issue title, use grey colour for the table heading etc.

Maybe also consider removing the shadow from the 2nd table since 1st table will be more "popped" compared to the 2nd.

To add on some suggestions with the 2 tables.

• As first table displaying bugs to be submitted and capped at a max of X bugs, I think it's good to remove the search bar and paginator or don't show it as long as X is below some value? This way the 1st table looked more focused

As for functionality behaviors

• Issues in the first table can be "moved" down to the 2nd table
• Issues in the 2nd table can be "moved" up to 1st table should there be enough space
• Issues in the 2nd table can replace an issue in the first table (show another button to mean replace) <-- suggestion?

[yucongkoo]

Thanks for your inputs @damithc !

Yes, can remove.

Okay, will remove as part of this PR.

No harm keeping it right? It allows a way to quickly recover from a delete-by-mistake case.

Yup, perfectly fine to keep it as it is.

2. View issue page for deleted issues, note that as the permission for users are granted to edit/delete/create issues during this phase, this page is totally same as the original view issue page (i.e. users can still edit deleted issues)

I'm wondering if we should do something to make the 2nd table look slightly different (and less prominent) than the first table. E.g., strike-through the issue title, use grey colour for the table heading etc.

Yeah I think this makes sense, from the outside we can strikethrough the title, then when users click into the ViewIssuePage we make a separate (less prominent) view of the it, with no functionality to edit/delete/create new issue (we should probably add a new button recover to be shown in this new view also?). I'm thinking shall this be a separate issue from this PR after we gather more suggestions?

[yucongkoo]

Thanks for your suggestions @Eclipse-Dominator !

Just remove the edit buttons or disable them should do this so keeping the page is good enough. This effectively removes all access to edit/delete/create issues, thus, "restricting" access by disabling these functionalities in the UI.

Yup, initially I was thinking that allowing them to have access on editing is fine, but after thinking more about it, although there is no harm allowing them to do that, it doesn't really make sense too.

Teams should also be able to set duplicates issues here as well.

If I am not mistaken, there is no concept of duplicate bugs in this bug-reporting phase (and the new bug-trimming phase too) right?

Might be worth considering if this should be turned into a new component or just add a phase check / @Input to the component

Yeah I am considering that this should potentially be a new component now, will discuss further with the team regarding this new component.

I'm wondering if we should do something to make the 2nd table look slightly different (and less prominent) than the first table. E.g., strike-through the issue title, use grey colour for the table heading etc.

Maybe also consider removing the shadow from the 2nd table since 1st table will be more "popped" compared to the 2nd.

Great idea!

To add on some suggestions with the 2 tables.

• As first table displaying bugs to be submitted and capped at a max of X bugs, I think it's good to remove the search bar and paginator or don't show it as long as X is below some value? This way the 1st table looked more focused

Hmm I have a different point of view with this, I think that a common scenario would be student reporting a bunch of bugs during the bug-reporting phase without deleting any, then they will end up with a lot of bugs in the 1st table initially during the new bug-trimming phase. The search bar and pagination will then become helpful in such scenarios.

As for functionality behaviors

• Issues in the first table can be "moved" down to the 2nd table

Yup this is the delete icon in the 1st table.

• Issues in the 2nd table can be "moved" up to 1st table should there be enough space

As suggested by prof Damith, we are not restricting the "space" in the 1st table, hence they can always move issues from the 2nd table up to the 1st table

• Issues in the 2nd table can replace an issue in the first table (show another button to mean replace) <-- suggestion?

This one sounds like a good idea! Will check with the team if we want to implement this in the future (probably not required in this first version of implementation)

[damithc]

• Issues in the 2nd table can replace an issue in the first table (show another button to mean replace) <-- suggestion?

This one sounds like a good idea! Will check with the team if we want to implement this in the future (probably not required in this first version of implementation)

Probably no need (especially for this version), as we want to keep CATcher functionality/code to a minimum.

Hmm I have a different point of view with this, I think that a common scenario would be student reporting a bunch of bugs during the bug-reporting phase without deleting any, then they will end up with a lot of bugs in the 1st table initially during the new bug-trimming phase. The search bar and pagination will then become helpful in such scenarios.

Yes, plus dynamically adding/removing the search will require more code/logic. So, can keep as is for now.