Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[issue_tracker] Add Batch Mode #9339

Merged
merged 30 commits into from
Oct 29, 2024
Merged

[issue_tracker] Add Batch Mode #9339

merged 30 commits into from
Oct 29, 2024

Conversation

ay-bh
Copy link
Collaborator

@ay-bh ay-bh commented Sep 15, 2024

Brief summary of changes

  • Implement new "Debug View" "Batch Mode" in Issue Tracker module
  • Add button to access the new view
  • Develop tabbed interface for organizing issues by criteria
  • Create issue management interface within new view

The following features will be implemented in a future PR:

  • Implement modal for adding comments and managing assignees/watchers
  • Create new permission issue_tracker_debug_mode_edit

Testing instructions (if applicable)

  1. Navigate to the Issue Tracker module
  2. Verify the presence of the new "Switch to Debug View" button
  3. Access the new view and confirm the tabbed interface for different criteria
  4. Test editing of issues, including changing description, status, priority, and category
  5. Verify that changes made in the Debug View are reflected in the main Issue Tracker view

Link(s) to related issue(s)

Demo

Demo.mov

@christinerogers
Copy link
Contributor

christinerogers commented Sep 23, 2024

Great start Ayush! Could you please embed here (or else link) the video, or screenshots are fine.
My comments below are based off the video shared last week--

For the missing modal - could this be fixed before this work is presented to the larger team at the end of September, to avoid confusion and so Debug mode can be fully useful --:
What's missing is the ability to review past comments and add further comments -- Please see where this is visible in the sketches in #9268. This means the Edit Issue button should be called New Comment and it should trigger a modal per the bottom sketch provided.

The reason why --:
We don't really Edit the Issue Description because that would modify/overwrite the original report coming from the client-user research team. So instead the person debugging the issue must add new comments and also review prior comments -- we realize this was not detailed in the #9268 text though quite visible in the design sketch.

@racostas @regisoc let me know asap if this has already been discussed among you.

Thanks Ayush, it's looking solid otherwise.

@racostas
Copy link
Contributor

Hi @ay-bh, I reviewed the PR and is looking like a good start indeed.
Yes, the functionality @christinerogers is mentioning it's important, I'm thinking now if it can be somehow be part if this same "view" in place of a new one ( do you think @regisoc that having the latest comments in this same view) will be defeating the purpose of the new view (because will be making the windows too big) or in facts can help to take the decision faster (without going throw the modal windows).
image

@racostas
Copy link
Contributor

@SantiagoTG, your inputs here are also very welcome since you have been working a loot with issue tracker. If you have time to take a look to this proposal you opinion is very important. Thanks.

@regisoc
Copy link
Contributor

regisoc commented Sep 26, 2024

@racostas @ay-bh to keep you updated, we did not have time to test that together with @SantiagoTG.
The video was looking good. We will try to update you later today.

@regisoc
Copy link
Contributor

regisoc commented Oct 3, 2024

Hello @ay-bh great start indeed! Here are some comments from both me and @SantiagoTG.
There is a lot to say, but I tried to be exhaustive and integrated description/images/gif to be clear on the reasons behind each point, so don't be discouraged! I love the clean design, and those are more enhancements than problems.

I tried to group comments:

  1. global view:
    1. Number of card displayed: How many cards are displayed? Some projects have lots of issues (e.g. around 14k on HBCD right now). Even with a filter active, it might be a very long list. Paginating them could be a good idea.
    2. Card ordering: Not thought at first but would be good: have an ordering system, e.g. order ASC/DESC by last comment date. Can be done later.
  2. cards/individual issues: looks good! Good and simple design.
    1. issue (?) card date not updating: I tried to update a card but the last update date was not updated. Maybe a bug on my end. Other data were updated.

    2. Display last comments: Going back to what @christinerogers and @racostas mentioned: having a quick view on the last few comments is important. It can be up to 3 (maybe?) but would depend on the space required for it. We could split the card horizontally, with the left side = description and the right side = last 1-2-3 comments. I do not think we have a restriction on the maximum height a description can have but we do not want to have cards too big on a screen. So, it could be a fixed max height, if the text in height of the description is more than that, it should be managed as an overflow (collapsible text area).

    3. Clearer disabled elements: if the ticket/issue is disabled, do not show it as a clickable dropdown element. it should be an unambiguously non-modifiable static text. Moreover, for each element, there should be a clear text to say which field it is i.e. category, priority, status. We only have 3 right now, but this will be changed.
      clipboard_2024-10-03_16-25

    4. New comment modal: Still missing the comment modal attached to the card, but this still looks good start.

  3. filters: more things to say here. Globally still good, and we can enhance than side.
    1. filter checkboxes with lots of items: having an inline list of elements works when there are few, but not on some projects with dozens of them. It will not be ergonomic (e.g. see gif after). A collapsible with a max height, overflow, and listed elements could alleviate that (see issue).
      Recording 2024-10-03 at 15 51 12

    2. Issue redimensioning text area: description label goes wild.
      Recording 2024-10-03 at 14 04 47

    3. Active filters indication: because we can travel from one filter on one tab to another, we can lose the active list of filters. E.g. activating a filter in status tab, then going to another tab category. The first filter is still active but we are not able to see it.
      Recording 2024-10-03 at 13 55 56
      Two things here to help on that side:

      • active filter tracking: something like a number of active filters on each tab title will be a good first step. Something like a badge/pill maybe.
      • reset filter button: a quick way of resetting all filters to the default (no active filters).
    4. Site as a base filter/tab: sending issue to people in different site, we could automatically apply some filters based on people location. Site should be a new tab.

That was a lot more to write than expected, but I tried to describe each point.
This PR is good work, and I am eager to see the next steps!

@racostas
Copy link
Contributor

racostas commented Oct 3, 2024

Hi @regisoc, very good review in facts. I'm sure @ay-bh can address all of this points before the end of the coding period (end of October). Maybe he can present some of the advances he had been making in two weeks from now. (then do a second final presentation in November 5). I will keep you posted with more details after consulting it with him because he have other commitments in the school as well.
I'm very happy with this first review. What he (and @christinerogers and myself) wanted the most if to have a work that users find useful... and as you mention there are already some steps in this direction.

@driusan
Copy link
Collaborator

driusan commented Oct 4, 2024

Can we also make sure this has a more descriptive name than "Debug View"? I suggest something like "Batch Mode" since that seems to be what it's doing.

@regisoc
Copy link
Contributor

regisoc commented Oct 4, 2024

@driusan @ay-bh oh yes I forgot this one :) Good point, batch mode is a good one.
I did not have any good idea the moment I created this ticket.

@ay-bh
Copy link
Collaborator Author

ay-bh commented Oct 6, 2024

Thank you all for your detailed feedback and suggestions. I'll start working on implementing these improvements.

@ay-bh ay-bh changed the title [issue_tracker] Add Debug View [issue_tracker] Add Batch Mode Oct 6, 2024
@racostas racostas added the Event: GSOC PR or issue accepted for Google Summer of Code label Oct 8, 2024
@racostas
Copy link
Contributor

racostas commented Oct 8, 2024

Hi @ay-bh, this two changes are looking good. Thanks for the update !
I will be continuously testing, feel free to push any change as soon as its ready since this PR can get big very fast and will be not to easy to test if we wait until all is addressed.

Great work !

Copy link
Contributor

@regisoc regisoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add with @racostas previous review:

  • pagination change at the bottom.
  • pagination starts at 10 (yes!).
  • link to all comments. Could be nice, but I think this one is less a priority. All comments can be accessed by clicking the issue ID/title for the full issue view.

Points to be addressed (previous review):

  • issues pagination: looks ok, but do not have enough issues to test. Maybe easier to test with a pagination at 10 ;)
  • issues ordering. Not a priority.
  • bug: issue timestamp not updating: resolved.
  • display last comments: looks nice!
  • clearer disabled elements: if possible, change dropdown to a label when it is disabled + add the actual label (category,priority,status). i.e. seomthing like category: aaa.
  • new modal for comments: partially done. Still needs to modify assigned/watchers but it looks simple and great. Tested with 5 paragraphs of lorem ipsum and still looks nice!
  • filter block: more genral comment here. The actual design is better but we still cannot track how many filters are selected. I was more thinking about something like this where: we can direct access to all filter in one click, have a visual hint on which filters have selected criteria (badge/number), and collapse the full filter section to focus on issues.

Untitled Diagram drawio(1)

  • bug: issue with description text area: ok.
  • filter reset button.
  • Site filters.

@racostas
Copy link
Contributor

Hi @ay-bh, very nice.
Now that we have the possibility of filtering by Site we might want to be able to edit this in the card as we are doing for Category, Priority and Status.
image

The rest very nice !
Great work !

@ay-bh
Copy link
Collaborator Author

ay-bh commented Oct 21, 2024

Hi @ay-bh, very nice. Now that we have the possibility of filtering by Site we might want to be able to edit this in the card as we are doing for Category, Priority and Status. image

The rest very nice ! Great work !

Thank you for reviewing, @racostas. Since @regisoc didn't mention it, and I felt it is not something that is updated regularly, I decided not to include it there to keep the UI clean. Instead, I added it just below the assignee on the top-right.

@racostas
Copy link
Contributor

Hi @ay-bh, very nice. Now that we have the possibility of filtering by Site we might want to be able to edit this in the card as we are doing for Category, Priority and Status. image
The rest very nice ! Great work !

Thank you for reviewing, @racostas. Since @regisoc didn't mention it, and I felt it is not something that is updated regularly, I decided not to include it there to keep the UI clean. Instead, I added it just below the assignee on the top-right.

@regisoc, according to your experience the site is something the change frequently ? I kind of agree with @ay-bh in this point but I want your inputs since you deal more with users than myself.

I other fronts, the rest of the PR looks good to me. All core functionalities and issues were addressed (in my opinion ). I thinks this PR is ready to be merged. The functionalities that were not high priority could be part of a second PR since this one is getting already big, what do you think @regisoc , @christinerogers ?

@racostas racostas self-requested a review October 22, 2024 13:49
Copy link
Contributor

@racostas racostas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
I reviewed and seems to be working fine. I think other functionalities could be addressed in a second PR.
Approved by my end !

@racostas racostas added Passed manual tests PR has been successfully tested by at least one peer and removed State: Needs work PR awaiting additional work by the author to proceed labels Oct 22, 2024
@christinerogers
Copy link
Contributor

christinerogers commented Oct 22, 2024

Great work @ay-bh in your Demo today and discussion with the whole LORIS team, this feature is well done and greatly appreciated.

Notes from today: nice to haves and issues for follow-up:

  • Cecile/Regis: batch-close multiple issues at once

  • Ayush's next PR will add ability to change assignee (also discussed above in this thread, among other minor features to add), as time permits

  • Old Issue Tracker page: will still keep because it allows sorting, Download in CSV, public view (so they don't file repeated issues)

Otherwise, no current blockers to getting this merged.
Next steps to ensure this gets merged by Nov. 4 (end of GSOC period):

  • re-review requested from @regisoc (oct 22)
  • @driusan to review (starting oct22) and go from there

Copy link
Contributor

@regisoc regisoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello all @ay-bh @racostas @christinerogers, I am happy with this result.
As I said in LORIS meeting, it is a really strong start for a feature that will be useful and is already waited in some cases/projects.

@racostas in my experience, no, site are not changing frequently, not an issue immediately, can be done later on. Already told Ayush that is the case.

I added comments. To sum up: 1/ finish the missing parts, then 2/ stress test this feature. The main goal of this feature was to have a new front-end i.e. an alternative view, but I suspect it can be long to load with lots of issues. Waiting elements to load is one of the main source of frustration.

From what I can see, points for next PR, ordered by priority:

  • assignee/watchers changes in comment modal.
  • permission to access this feature, as I do not see it required nor useful for all users (can be discussed).
  • Change the switch mode button to another, more convenient location. Maybe close to new issue (button only appearing with the right permission).

Screenshot_2024-10-23_09-47-24

  • site change in card main panel.

Points later on (because not part of the original ticket/issue, but still important):

  • stress test i.e. push 1k, 5k, 10k, 20k, 50k issues with various number of comments and see how the feature behaves.
  • order card elements in main panel.
  • batch-close multiple issues at once.

Still, big thanks @ay-bh for this PR, great work!


if ($batch_mode) {
// Fetch all issues
$allIssues = $this->_getAllIssues($user);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we reload all issues every time the batch mode is selected? Maybe something to memoize for both sides or use a lazy loading strategy.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a different endpoint with different fields, for e.g. top 3 comments, So memoizing might not make sense. Also the user may not toggle between the modes frequently.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be right on the fact they will not change frequently.
I just want to make sure it does not affect too much the wait time.
Good for now.

import PropTypes from 'prop-types';
import swal from 'sweetalert2';
import Modal from 'jsx/Modal';
import '../css/issue_card.css';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normally we inject css from php, but no php backend specific to these new elements, looks ok.

Comment on lines +404 to +437
IssueCard.propTypes = {
issue: PropTypes.shape({
issueID: PropTypes.number.isRequired,
title: PropTypes.string.isRequired,
reporter: PropTypes.string.isRequired,
assignee: PropTypes.string,
status: PropTypes.string.isRequired,
priority: PropTypes.string.isRequired,
module: PropTypes.number,
dateCreated: PropTypes.string.isRequired,
lastUpdate: PropTypes.string,
lastUpdatedBy: PropTypes.string,
sessionID: PropTypes.number,
centerID: PropTypes.number,
candID: PropTypes.number,
category: PropTypes.string,
instrument: PropTypes.string,
description: PropTypes.string,
PSCID: PropTypes.string,
visitLabel: PropTypes.string,
topComments: PropTypes.arrayOf(
PropTypes.shape({
issueComment: PropTypes.string.isRequired,
dateAdded: PropTypes.string.isRequired,
addedBy: PropTypes.string.isRequired,
})
).isRequired,
}).isRequired,
onUpdate: PropTypes.func.isRequired,
statuses: PropTypes.object.isRequired,
priorities: PropTypes.object.isRequired,
categories: PropTypes.object.isRequired,
sites: PropTypes.object.isRequired,
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a chunky element!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's actually all the data that's coming in issuecard. I wrote it this way so it's clear what all we have. If it's too big, I could maybe just write issue: PropTypes.something, but this way someone else working on this in future may not know what all we are receiving.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues, that is fine. Having all in one place is actually very representative of the central element.
I just did not realize it was that big :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a picky question: why using this file (i.e. edit.class.inc) instead of issue.class.inc for retrieving all issues? Not important, just curious.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The get issue logic for an individual issue (when editing the issue through traditional view) is in the same file.

@racostas
Copy link
Contributor

Hi @driusan. This one it's ready for final review.
@ay-bh will be working in the "not priority" features in a second PR. @regisoc made a summary issue here #9418

If you have time to final review this one it will be great since he have less than 2 weeks now to wrap up all his work (including a PR for the "not priority" issues)

Thank you @driusan and sorry for this been need with a bit of pressure from our side.

@christinerogers christinerogers added the Priority: High PR or issue should be prioritised over others for review and testing label Oct 25, 2024
Copy link
Contributor

@christinerogers christinerogers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this comment is relevant to #9422, should not block this PR @ay-bh

Copy link
Collaborator

@driusan driusan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reservations about the use of fragments and the way the getAllIssues query is a hardcoded database query instead of using the issues provisioner but not enough to block the PR

@driusan driusan merged commit c6cd1da into aces:main Oct 29, 2024
10 checks passed
driusan pushed a commit that referenced this pull request Oct 30, 2024
#9339 got merged after #9430 without rebasing, which allowed some wrong
indents to be committed to main.
ZhichGaming pushed a commit to ZhichGaming/Loris that referenced this pull request Nov 25, 2024
Add a new "Batch mode" view to the issue tracker which allows users to modify many issues in bulk, rather than having to go into each individual issue to modify them.

* Resolves aces#9268
ZhichGaming pushed a commit to ZhichGaming/Loris that referenced this pull request Nov 25, 2024
aces#9339 got merged after aces#9430 without rebasing, which allowed some wrong
indents to be committed to main.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Event: GSOC PR or issue accepted for Google Summer of Code Passed manual tests PR has been successfully tested by at least one peer Priority: High PR or issue should be prioritised over others for review and testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[issue tracker] Alternative view for issue hunting
5 participants