Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Bug Jira issue tracker connection: "Create branch" only displays "random" 50 non-useful(ancient) tickets

Discussion in 'Unity Version Control' started by Wolfram, Jul 19, 2023.

  1. Wolfram

    Wolfram

    Joined:
    Feb 16, 2010
    Posts:
    253
    • We have several Jira projects on our Jira Cloud, with several thousand tickets in total.
    • We have the Plastic client issue tracker connection configured.
    • For some repos, we need to use the MULTIPLE_PROJECTS keyword as "Project Key".

    Problem 1:
    In the "Create branch" dialog, I seem to remember the displayed tickets were at some point sorted by "most recent", so that I can quickly choose the ticket I want.
    However, after clicking one of the table column headers it now ALWAYS sorts alphabetically up or down according to that column, and there does not appear to be a way to "unsort"/disable this and revert to the default "most recent" sorting. So I can no longer find the most recent "MAIN" ticket, since reversing the sorting or scrolling to the bottom will show projects starting with another letter instead (such as "NARD"):
    Screenshot 2023-07-19 185706.png
    => please allow "disabling" this sorting, or much more convenient and helpful: add a "ticket creation time" or "ticket last modification time" column, and let us sort by that.

    Problem 2:
    The sorting via the first column (="ID") is purely lexicographic - which is completely unhelpful for numbers:
    Screenshot 2023-07-19 190150.png
    , so to find the latest ticket of the "MAIN" project, I need to manually scroll through the teensy-weensy 5-line-scrolled-list to actually find it (=in my example that would be MAIN-1843).
    => please fix/extend that sorting to numerically "useful" sorting, or pad all ticket numbers with sufficiently many leading "0"s, so that lexicographic sorting works.

    Problem 3:
    Even after setting the "Issue query limit" to a value larger than 50, the resulting list STILL only shows 50 tickets (setting it to a number smaller than 50 actually works - but it's not helpful).
    Screenshot 2023-07-19 191548.png
    In addition, in our MULTIPLE_PROJECTS use case (and especially apparent when checking the "Display pending tasks from all users", which we sometimes need to do):
    Screenshot 2023-07-19 191637.png
    , the 50 tickets displayed are ANCIENT tickets from some random/old projects (seems to me from a Z-to-A sorted project list, as the list only contains projects starting with Z/W/V), and NONE of our currently active projects/tickets are shown.
    Also, tThe "Filter" search field cannot be used/does not help here, as it apparently only filters the 50 originally returned tickets, instead of re-querying the Jira server with the new filter settings (in the hopes of returning 50 more useful matches...).
    So currently, in our use case we CANNOT select a recent/relevant ticket, unless it is assigned to us (AND the total number of all the tickets assigned to us across ALL projects also doesn't exceed 50...), therefore we cannot create a branch that is connected to the correct Jira ticket (unless we manually name it according to the correct scheme, and figure out the ticket number ourselves...).
    => please allow queries returning more than 50 entries, and/or query only for "recent" tickets, and/or improve the use of the "Filter" field (by re-submitting a query to Jira after changing that field)

    Thanks!
    Cheers,
    Wolfram
     
  2. ollieblanks

    ollieblanks

    Unity Technologies

    Joined:
    Aug 21, 2017
    Posts:
    429
    Hey @Wolfram,

    Thanks for reporting these...

    RE: Problem 1
    The column sort info is stored in the plasticgui.conf file in the local configuration as the taskstable.sortcolumn value. I also find it very frustrating that this sorting cannot be removed, and I will report this to the team to be fixed.
    P.s. To remove this sorting manually, you can close the client and delete this entry within the file.

    RE: Problem 2
    I couldn't agree more! The current lexicographic sorting method is not the most efficient for its use case. I suspect the developers expected users to utilise the filter functionality rather than trawling the list. I have logged this as a Feature Request with the team.

    RE: Problem 3
    Oh! The filter field also has a defect meaning it is not as effective as it could be (facepalm). I believe a small improvement here can make a big impact, so I have again raised all of your suggestions with the team.
     
    Wolfram likes this.
  3. Wolfram

    Wolfram

    Joined:
    Feb 16, 2010
    Posts:
    253