DevOps doesn't show all matching stories/tasks when searching - azure-devops

I can start typing "#per" in a Devops task description/comment and it brings up suggestions. However it only shows a subset of all the stories which means the one I want is rarely listed and I have to go look it up.
For instance I have two work items (on the same epic) called "perform analysis" and "determine permutations" but typing "#per" only shows the second one.
Is there some logic used in the searching based on item fields that could be to blame i.e. it's a feature rather than just not working well?

Normally, when using the #mentioned to link work items, the expected syntax is #{ID} instead of #{Keyword}.
If using the syntax #{Keyword}, it may be not able to return the expected result. So, it is recommended using the #{ID} as possible to search and link work items.
For more information, you can reference "Link work items".
[UPDATE]
When you use #{ID} to search and link a work item, normally it will prioritize the work items that you've recently modified or are assigned to you.

Related

GitHub: filter for issues that are either assigned to somebody or somebody is mentioned

Is there an option how to show all issues that are either assigned to me or that I'm mentioned in at the same time? Filtering by using the dropdown menu allows only to check for one of those and using is:open assignee:#me mentions:#me filters for all issues for which both constraints are true (basically & instead of |)
The first answer to this question from 8 years ago suggests it is not possible to use an "or" query. Does this still hold true?
What is the best alternative to filter for all issues that are relevant for me, ideally in the whole organization - third party tools?
The involves:user may be useful here:
Search by a user that's involved in an issue or pull request
You can use the involves qualifier to find issues that in some way involve a certain user. The involves qualifier is a logical OR between the author, assignee, mentions, and commenter qualifiers for a single user. In other words, this qualifier finds issues and pull requests that were either created by a certain user, assigned to that user, mention that user, or were commented on by that user.
Simply searching for the user's Github handle may be useful too.
Using a tool like gh (github cli) will allow you to lest and filter items too. A script can easily concatenate the results:
gh issue list --search "involves:#me is:open"
You can have it spit out json as well by adding --json, that way you can parse and further process the results as well.

Azure DevOps Migration - Moving Project to Another Org

I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.

Kentico Import Tool inconsistent/buggy when updating documents

I've had a number of problems using the provided Kentico Import Toolkit, namely when using the "Import new and overwrite existing pages" option to update my existing/already imported pages. I'm using a custom SQL query to import and have had a profile saved for each import I've needed (client has article based site so a few tables of similar information) to try and keep each as consistent as possible between imports.
Here's the problems I've encountered thus far (in no particular order):
the tool tries to guess which fields from the query correlates to the fields of the page type in Kentico for you, which is a nice idea, but seems poorly implemented. If I'm not very careful and reload the profiles every time I import I've had instances where fields changed inexplicably when testing imports because the tool thought it knew which field I wanted
this is more the problem when importing/reimporting multiple times in a session and choosing to go back and load the same profile (without reloading)
the NodeAlias field is only seemingly required on update/reimport rather than on initial import. I'm sure there's an internal cleaning of the document's title to generate a NodeAlias and this is generated fine when importing documents while NOT providing the NodeAlias. After importing the items initially and wishing to update however the NodeAlias is seemingly required as you'll get errors with text asking it be included. This implies to me that there's matching of the NodeAlias along with the given ID field, which should be fine in theory but isn't specifically mentioned anywhere in the tool as best I can tell.
I've had instances where reimporting items will change/strip their NodeAliasPath. I've gotten around this by specifically setting the NodeAliasPath (which only shows after selecting "Show Advanced Columns") but like NodeAlias path before it, I'd think the tool should be smart enough to know to keep the path if not specifically given for updated items.
it seems very odd that in order to match on ID for previous items you have to provide the name of the new column instead of the old one. My example: client was using just a field named 'id' and the new one is 'OriginalID' to clearly differentiate it from the Kentico derived ID fields. To match the items I have to use 'OriginalID' rather than 'id'
A couple of notes/niceties or potential updates along with the above:
it would be nice if there were some way to select if the page should
be published or not through a single query. Currently having the
"Automatically publish pages under workflow" toggle checked seems to always publish
the items. I have an instance where the client has old documents in
the provided DB dump that they don't want visible on the site but
want preserved in the DB if they change their mind later. Currently I
have to perform 2 imports, 1 for the unpublished and a second for the
published items, to accommodate this, which is quite cumbersome
I'll likely edit/add to this as I get responses. This isn't really a specific problem (as I managed a workaround to the NodeAliasPath stripping problem, which inspired this post initially) but more just me asking if these are bugs,if I'm not using the software as intended, etc.
You've stated all the problems you're having/experiencing and possibilities why they are happening but didn't ask a particular question. If you suspect they are bugs, then I'd go to directly to Kentico Support and report the issues there since these are things that have been part of the KIT for as long as I have worked with it.

Use Followed work Item in a new Query TFS 2017

I want to create a query with my followed works items in TFS 2017, but I didn't find the field name for the followed state.
I want to create that query in order to add a new widget in home dashboard.
Is it possible to make a query with your followed items in TFS2017?
No, there isn’t the feature to create a query with followed work items in TFS or VSTS and pin to dashboard. You just can check followed work items from Work>Queries.
I submit a user voice here (Query for followed workitem and pin to dashboard), you can vote it.
You can achieve this scenario by creating a custom Followed work items query (System.ID In #Follows) and saving it to Shared Queries. Then, simply pin the query to your dashboard as a Query Results Widget and anyone who views it will see their followed work items (similarly you can pin an Assigned to me query using the #me macro and users will see items assigned to them).
The #Follows macro has been around in VSTS for awhile and was introduced in TFS 2017. Check out our documentation on queries macros for more information.
As proposed by Lauren, in TFS 2017, you can build an ad-hoc query "ID In #follows" (Field=ID / Operator=In / Value=#follows). The results will be similar to the Default Query "Followed work items" under Work>Queries.
However, I was never able to save this query: trying to save always got me an error "TF212023: You cannot compare fields with different data types in the WHERE clause of a work item query. The error is caused by «[System.Id] in (#follows)»."
What I found out is, that the query works well in the web interface, but cannot be run nor created or edited in Visual Studio.
I did not even find a way to "follow" a workitem in VS, this seems to be available only in the web interface as well.

How do you keep track of your comments on GitHub issues?

I want to find all the GitHub issues that I commented on. I tried searching for commenter:mbigras type:issue like the Searching issues and pull requests GitHub article suggests. But that method returns fewer results than the public activity section of my profile.
See both attached images:
Search method
Doesn't display current results:
Profile method
Gets mixed up with other public activity:
Is there a way to get the full history of my comments on GitHub?
EDIT
author:mbigras type:issue gives wider results but still not the full history:
What I'm looking for is a way to quickly view all my comment/issue history in all issues.
EDIT
I emailed GitHub about this. Search doesn't match the public activity section because search indexes issues by creation date and not last active date.
How do you keep organized about which issues you've commented on?
Search for commenter:username in the main Github search box.
For example commenter:gavinandresen
To see recent activity, select Recently updated from Sort dropdown
You can also narrow the search: is:issue commenter:gavinandresen
I have also been very frustrated when I could not find an issue that I have commented on a while ago. I even did not remember the project it was in. I knew only the problem I was referring to.
Then, I went to the Notification settings on Github and saw there is an Include your own updates option that is unchecked by default.
Once you check it, Github will send you an e-mail notification about every comment or PR you make. They you probably want to add an appropriate label and filter for emails so Github messages do not clutter an inbox.
My life has changed since then. Now, every time I want to find something I have written on Github, I just search for it in the e-mail notifications.
You can view all the issues on Github you have commented on by going to https://github.com/notifications/subscriptions and selecting Reason as Comment.
This will show all the issues that you've commented on.
You can also filter the issues by selecting other reason such as Assign, Author, Manual, Mention, etc. but you can select only one reason at a time. Also, you can filter the issues by repository by selecting the concerned repository from dropdown after clicking Repository
Search All GitHub using the search term is:issue author:#me
You can also check the following links.
For all your subscriptions
https://github.com/notifications/subscriptions
For all your issues
https://github.com/issues
For all your pull requests
https://github.com/pulls
In case someone is interested to know how to find these links, go to github's resi api documentation. The URL's are not explicitly described there. However, look for the page names bellow REFERENCE.
If you lowercase the relevant word (for example Issues become issues, Pulls become pulls) and put that after https://github.com/, you most probably will find what you are looking for.
This might be a little late, but there's also another way to find what issues/PRs you have participated in. This method also brings in a lot more things you might be interested in too!
When you are on the website main page, on github.com, use the keyboard shortcuts as described here to open your pull requests or issues. The shortcut for these is in particular [g, i] for issues and [g, p] for pull requests (I remember g by go, but whatever works for you.)
After you go to the page directed by these shortcuts you are greeted by an entire screen of goodies you can use! The search bar can be edited and the buttons can be used to make your experience fast!
Type involves:<your username> in the search box on the GitHub's main page. This will find all the issues that you commented on, was assigned to or mentioned in.
For example, if your username on GitHub is unclebob, the search query should look like:
involves:unclebob
Or if you're logged in to GitHub, then simply:
involves:#me
Note the difference between involves and similar search qualifiers - author and commenter:
author will find only the issues that were started by you; if you comment on the issue that was started by someone else, author query won't return it in the search results.
E.g., compare involves:unclebob and author:unclebob type:issue.
commenter will find only those issues where you commented second or later (creator of the first comment in an issue is considered its author and not a commenter); if you start an issue and then never comment on it, the commenter query won't return it in the search results.
E.g., compare involves:unclebob and commenter:unclebob.
In other words, when it comes to searching comments, author and commenter return only a subset of involves' results. So I recommend using involves not to miss anything.
Also, since Github is on the web, any HTTP search engine works, eg Google, Bing, etc. This works to the extent of your search engine's quality and the uniqueness of the writer name.
(Indeed, I actually do this all the time when I need to find any previously written web (engine)-accessible publication, including those on StackExchange. Names I use are 1 in probably an infinity, so Google often works better than forum search options.)
(Sample Google link.)
If you want to search for multiple users in a single search, use it like in the global search bar without the OR logical conjugation:
commenter:FantomX1 commenter:FantomX1-github
since the similar google way approach with 'OR' would not work
commenter:FantomX1 OR commenter:FantomX1-github