Is there a way of changing the default sort in Gitlab issues tracker from "Newest" to "Recently Updated"?
I understand I can change it by just selecting the sort filter, however, doing this every time becomes annoying quickly.
does anyone know if there is a way of changing the default sort in Gitlab issues tracker from "Newest" to "Recently Updated"
Not that I know of (mid 2014):
there is no issue in the GitLab CE project
the one issue in GitHub GitLab project (April 2014) refers to the GitLab CE project
There are a few suggestions, but none regarding the default sorting order
there is nothing in the main config gitlab.yml file
That could be a good PR (Pull Request) to make, starting with:
app/helpers/issues_helper.rb, which sorts issues by name
app/models/project.rb, which also sorts issues by name
app/views/projects/issues/_issue.html.haml which lists issues by name
Update January 2016: as mentioned by stevenw00 in the comments, there is now issue 5546
As a user frequently viewing a list of issues (or merge requests), I want to be able to have the list sort I use remembered, so that I do not have to constantly set the sort when ever I view a list of issues (or merge requests).
Update Dec. 2018 with GitLab 11.6
Per-user saved sort order in issues, merge requests, and epics
There are now user-specified sort order selections in issues, merge requests, epics, and even roadmap views.
Which type of attribute you choose to sort by, and in which order you choose to sort (ascending or descending), is saved to the system, so that when you return to the same type of object list, it will remain what you have selected previously.
Update August 2019, GitLab 12.2
Manual Issue List Sorting
As of 12.2, you can now sort an Issue List in Manual mode, which allows you to drag and drop Issues within the list to assign them a relative order.
The order is persisted and maintained across the entire instance for all Project Issue Lists and Group Issue Lists that have Manual mode enabled
See documentation and issue.
With GitLab 13.7 (December 2020), you have a new (non-free) option:
Sort issues by the number of issues they are blocking
While prioritizing a list of issues in GitLab, it’s often important to determine the critical path and whether an issue is blocking other issues.
With the current issue list, it is impossible to see which issues are blocking other issues. The only way to do so is to open each one and see the list of blockers below the issue description, which is a very time-consuming task!
As of 13.7, you can now use the filter for “Blocking” on any issue list, and you will see a list sorted by the number of blockers.
https://about.gitlab.com/images/13_7/sort-issues-by-blockers.png -- Sort issues by the number of issues they are blocking
See Documentation and Issue.
So, I found a couple of things.
Modified the following file:
app/controllers/projects/issues_controller.rb
On line 29, change from:
sort_param = params[:sort] || 'newest'
Change to:
sort_param = params[:sort] || 'recently_updated'
Modified the following file:
app/views/shared/_sort_dropdown.html.haml
On line 7, change from:
Newest
Change to:
Recently updated
However, still have an issue, it now shows Recently updated as the default option in the menu, however, it doesn't actually apply the sort. They still sort by default as newest.
Any further opinions :S
Related
How can I bind an issue to another issue, such that it will trigger the other issue to do something?
In the upper example, when "explicit device" issue is moved to "finished" column, I want the "error handling"(leftmost) issue to move to "in progress" column automatically. Because I may not remember which needs what and what was which, needing to check all issues whenever an issue is finished and would become tiring after some point.
Even better, building an issue tree, finishing from ground up without stopping by all issues for just finding the closest root of an issue, isn't an option?
Another example:
add method is written: "issue1" complete
multiply method is written: "issue2" complete
suddenly, a multiply-add method as "issue3" pops in the beginning column or if it is already there, it moves to right by 1 column.
The notion of project board presented in GitHub Universe 2016 is still lacking in term of fine-grained issue management.
That is why you have so many third-party integrations, including ZenHub (free for small teams and public account), which does have more features.
The point is: look for third-party integration (with a free offer) for your feature.
Sonarqube issues view shows only violations against top 15 rules, Is there a way I could see a list of all rules with issues count.
Both ProjectIssueFilter and IssueFilter show only 15 issues in the view. The filter shows this message "Only the first 15 results are displayed". Is there a way to see the complete list?
No, it is not possible to see more rules (writing at the time of SonarQube 6.1). It is planned to be improved. You can vote and follow the ticket https://jira.sonarsource.com/browse/SONAR-6400.
A trick I use to see more rules:
filter on Directory and/or Files.
You can sometimes see more rules, which was previously not visible.
Select the previously hidden rule(s).
Remove the filter on Directory and/or Files
You will still see the hidden rules with all the occurrences
It's a bit a pain, but it works...
I'm using SonarQube 5.3 and it seems that the issue count is different depending on the view I use.
Consider this pic:
if I look in Dashboards -> Issues I see
the numbers on the top left
if I click the grand total (267,877) I end up in the Issues dashboard where I see totally different numbers (bottom right)
Even on the main dashboard I see conflicting data (pic)
Why don't the numbers match? Am I missing something?
There is a difference between Measures and queries run on Issues : measures are collected during analysis time and stay like this until the next analysis. Queries on Issues are updated in real-time according to the changes you do on Issues.
From what I see, we can suppose the 267K Issues is correct and you have some trouble in your SearchServer stack preventing it to be up to date.
You have to check in your sonar.log for ElasticSearch errors and be sure to have enough free disk space available on SQ_HOME/data/es to store and update your Issues.
What you can also do to confirm this, is to stop your SQ Server, clean the data/es directory and restart your SQ. Data should be consistent after that.
I use multiple buildboxes which have StarTeam in them. I see a peculiar thing: all buildboxes differ in checkout label. Is there any specific setting to be done so that I can maintain a uniform default checkout label so that I don't need to change the desired label from the drop down each time for all buildboxes?
Jeremy Murray said:
I don't quite get the question - when you go to the checkout dialog,
the ordering of the labels is different from machine to machine?
In pre-2005R2 clients, the labels would be in order of creation time.
In 2005R2 and later clients, they should be in alphabetical order.
I think this has to do with the java version used, actually,
as we had some weird dialog differences on identical client installs with different java installs.
Here is my use case:
I start on a project XYZ, for which I create a work item, and I make frequent check-ins, easily 10-20 in total. ALL of the code changes will be code-read and code-reviewed.
The change sets are not consecutive - other people check-in in-between my changes, although they are very unlikely to touch the exact same files.
So ... at the end of the project I am interested in a "total diff" - as if there was a single check-in by me to complete the entire project. In theory this is computable. From the list of change sets associated with the work item, you get the list of all files that were affected. Then, the algorithm can aggregate individual diffs over each file and combine them into one. It is possible that a pure total diff is uncomputable due to the fact that someone else renamed files, or changed stuff around very closely, or in the same functions as me. I that case ... I suppose a total diff can include those changes by non-me as well, and warn me about the fact.
I would find this very useful, but I do not know how to do t in practice. Can Visual Studio 2008/2010 (and/or TFS server) do it? Are there other source control systems capable of doing this?
Thanks.
You can certainly compute the 'total diff' yourself - make a branch of the project from the revision just prior to your first commit, then merge all your changesets into it.
I don't think this really is a computable thing in the general case - only contiguous changesets can be merged automatically like this. Saying it's 'unlikely' for others to have touched the files you're working on in the interleving commits doesn't cut it, you need guarantees to be able to automate this sort of thing.
You should be working on a branch of your own if you want to be able to do this easily.
The ability to generate diff information for display or for merge purposes is functionality provided by your version control system, as Mahesh Velaga commented on another answer. If you were able to compute the diff by cherry-picking non-contiguous changesets, then logically you would also be able to merge those changes in a single operation. But this is not supported by TFS. So I strongly suspect that the construction of the cherry-picked diff information is also not supported by TFS. Other version control systems (git, mercurial, darcs come to mind) might have more support for something like this; I don't know for sure.
From my reading of their answers on the TFS version control forums, I think that their recommendation for this would be to create a branch of your own for doing this work in the first place: then the changesets would be contiguous on that branch and creating the "total diff" would be trivial. Since it sounds like you are working on an independent feature anyway (otherwise a diff of only your changes would be meaningless), you should consider having an independent branch for it regardless of whether your version control system is TFS or something else.
The alternative is to construct what such a branch would have looked like after the fact, which is essentially what Jim T's answer proposes. You might prefer that approach if your team is very keen on everyone working in the same kitchen, as it were. But as you are already aware, things can get messy that way.
Create two workspaces. Get Specific Version for files specifying the date or upto those two changeset on those two workspace. Now compare folders using a compare tool. Araxis merge is best one.
sounds like you need a tool that supports changesets (changes over multiple files and committing them all at once) instead of committing each file alone
take a look at this comparison between sourcesafe and mercurial ( free and you can find tools to integrate it with visual studio )