I'm looking to reproduce the Jira watch functionality in TFS 2013. In Jira, you can click a link to watch an item and thereafter you will be notified when anything on that item changes.
I know on TFS you can:
be emailed if anyone changes a bug you are assigned to
manually email a bug to anyone at any time
Create a custom report and pin it to your home page to notify yourself of things (like this maybe?)
I can imagine creating a new field that will accept multiple users and creating a custom email notification to notify everyone in that list if the work item changes. But that seem like a whole lot of work and I'm not sure were to start if that is the way do do this.
What's the easiest way to get functionality like watching a work item? If it's easy and similar to the Jira functionality that is better for me than exactly the same and hard to do.
Sure, you can setup email alerts based on many different criteria, including what you asked for.
You need to go to the Alerts section, and create a new custom alert, and you can put in the ID of whatever work item you want to "watch". By default it includes the clause AuthorizedAs <> [Me] which will make sure it doesn't email you for changes that you make, but you can remove that clause if you'd like.
Related
I am running Azure DevOps 2019 RC1 with an Inheritance Collection and a new Agile project.
I have a requirement that when a user creates a work item (task/issue), they must automatically be added as a follower of this work item. How can I achieve this? I have look in the rules for the work item under process customisation but it doesn't appear to be possible this way.
We are using the tickets to track issues. Whoever discovers the issue raises the ticket. The basic requirement is that anyone who raises a ticket should be automatically notified of its progress, even though they are not responsible for the development or testing.
Currently the work around is telling the user that when they create an issue they must click the Follow button, but it is easy for them to forget and then lose their updates. It seems like a very simple customisation so maybe I'm missing the obvious.
Thanks
I think you can't auto follow things currently, but you can add notification setting that will send automatically emails when work item is updated. To do this, go to Project Settings > Notifications page and create new subscription. Select "Work/A work item is changed" and put "Members of ... team by role" in Deliver to selection. Set roles to "Created by" and untick the "Skip initiator".
Your problem would be addressed precisely with the feature requested in the official Azure DevOps' feedback platform here:
479189 - Automatically follow work items I interact with
(That page also mentions workarounds, including per-team one answered here, and a per-person alternative. See this comment. The shortcoming of both is that they don't allow to you to unsubscribe for selected tickets.)
I've allowed my Stakeholders to create Work Items but I would like to restrict them to only be able to create bugs and NOTHING else. Currently they can create ANY Work Item type including Epics... I'm thinking there has to be a way to stop this but I can't seem to find it.
There is no setting for this. And there is already a similar feature request submitted on VSTS User Voice: Hide Work Item Types (WITs) based on permission/security group.
I am new to Jira and I have issue when some of the users are not getting email notification when someone tags them in a comment of the story.
My suggestion is to create outlook group and then I can add that as group in Notification scheme.
Along with that I would like to know how User Custom field value and Group custom field value works.
Any information along these lines is appreciated.
Thanks
About notifications:
add your users to jira, and set emails
create your groups (or roles) depending on what make more sense.
Then add users to groups
go to Admin>issues>notifications schemes> : create your scheme
Set notifications to your scheme, adding people to each event
There is a notification called "issue commented" or something similar.
Click add. Select Group(or role), and set wich group should be notificated
About the mentions, it is automatic, but you have to ensure your users are in the jira users directory and not only in a MActive Directory or whatever (if i remember ok):
http://blogs.atlassian.com/2013/06/using-watchers-and-mentions-effectively/
Say you and a coworker both discover the same issue; obviously, only one of you should file it. In the description you can quickly use an #mention to loop your colleague in on the issue. When you submit the issue to JIRA, they will get one notification that the issue was filed. That way, they don’t file the issue thinking that you didn’t. The benefit of using an #mention over adding them as a watcher is that they only get notified once.
About this question :"Along with that I would like to know how User Custom field value and Group custom field value works."
They works really similar to usual users and groups. What's your problem with them exactly.
Regards,
I am using a jira mail handler to automatically create tickets whenever email comes to a particular mail id. However many of the users who are sending mails are part of jira users and jira will create the issue with creator as their name. Later looking at the tickets is there any way to identify whether the ticket was created from email or the user manually created it. Thanks in advance
I think, it is not possible automatically. What about using a extra customfield? this way you can fill that new field, with the value you want: one for manually opened tickets, and another for email opened tickets. You can show or hide this field, and this would allow you to look for manually opened using jql (even it is not your first need :) )
For making it more visual, then you can use a bit of proggramatic magic and represent the values with icons or wahtever.
Let me know if it is not clear or if you need help for adding the new field or whatever.
Edit: the easiest way for doing this could be add to every issues opened by mail, at the begining of the summary something like "from mail:" and then the real summary. Anyway probably better if you customize the handler or create new one
Regards
I am setting up a tfs 2013 environnement,
In a Scrum team project, we would like a few users to be able to create backlog items and tasks, but we would like that other users to only be able to change the task their are assigned. Or at least we would like that these users can modify existing tasks, while not being able to create new one, or move them to other sprints
at this time, with the security parameters i have found, i can only either allow a user to do everything (create and move a backlog items from a sprint to another, modify it, delete it...), or nothing (if you can't create or move, you also can't modify an existing one...)
any clue how i could proceed ?
We have custom work item types and we prevent users from creating certain work items by editing the WIT's xml and including this in the transition between nothing and the "New" state. [global]\TeamSystem-TaskCreation is a TFS security group with a limited set of members.
<TRANSITION from="" to="New" for="[global]\TeamSystem-TaskCreation">
There is no real way to do this I'm afraid. TFS does not have many fined grained access controls, the impression I get is that it is designed to empower people and not restrict them.
You should be able to ask people not to change tasks, if that is your way, and use the Work Item History and/or Alerting functionality to know when they have done something you don't want them to. For example, and task changes not by approved people sends and e-mail to the leads.