I want what change work item state was strict like my work flow (not allow move work items to any state) or shall do warning about incorrect state.
This feature on preview only. You can find documentation here: Restrict state transitions. If you want to test it you should request this feature.
If you are interested in participating in the private preview, please
email us directly with your organization name.
Related
I don't want to subscribe a slack channel to all issues on arbitrary third party repositories, just to the particular issues on which my team/organization is involved (contributing to / impacted by), so the usual github integration command /github subscribe thirdparty/arbitraryrepo issues does not suffice as it would cause a ton of unwanted noise in the channel. (and the existing label filtering would not cut it)
(Update: there is an open feature request for that https://github.com/integrations/slack/issues/1280)
I neither want to forward my personal github subscriptions to the slack channel as there are lots of projects I am individually involved that have nothing to do with my team's work. (e.g. my direct mentions)
Also, subscription should stay despite I leaved the team/company.
A per-issue public RSS/Atom feed would cut it but it does not exist.
Am I missing something obvious?
The only workaround I can think of is adding a channel email integration, registering that address to an organization-shared github account and subscribe it to the individual issues we run into.
But this is quite cumbersome (must keep an alternate github logged-in session while browsing, channel readability could be abused to hijack company account, subscriptions can't be managed from the slack channel...) so any different idea would be very welcome.
As far as I know there is nothing that would suit your need completely at this moment, but have you considered labels?
#1 option You could use filtering based on label which seems to be the closest:
That would notify you about all issues, pulls, commits, releases, deployments that has a given label. Syntax example:
/github subscribe repo-owner/repo-name +label:"team-a"
Pros: a general filter based on a label name, e.g. team-a
Cons:
a single label filter only (AFAIK: multiple labels aren't supported but discussed: https://github.com/integrations/slack/issues/384)
this works only for a label given when issue/PR is created. Not during its existence ("change label" events are not triggered). Known bug (https://github.com/integrations/slack/issues/1594) and feature PR is open https://github.com/integrations/slack/issues/965
Note: a workaround to get info about label change in PR: to convert PR to a draft and back (https://github.com/integrations/slack/issues/965#issuecomment-1330884166)
#2 option Another thing that might be considered is that the account that is used within GitHub Slack app for connecting to Git server will be actually notified also about all its mentions, assignments & reviews! So if you don't use your personal account, you could get generated some related notifications to the whole team / other specific user etc.
EDIT:
Workaround steps to achieve partially what you want (but it can be in some conflict with your Slack / GitHub settings that I’m not aware of):
Use / create a shared account (or other special account) in GitHub
In Slack, use this special GitHub account for connecting Slack GitHub app to GitHub (this enables notifications by default for this account - mentions and assignments).
Then, when this GitHub account is assigned / mentioned, you’d automatically get notified (but again, then it would work not just for issues but hypothetically also in PRs etc.) to a dedicated channel where you'd have your GitHub integration set.
To auto-assign an issue, you'd have to use e.g. GitHub Actions.
Caveat: But as we discuss, there’s no simple way to achieve your goal completely. To at least get closer to something similar to what you describe and require, you’d need to accept some compromises and extra steps for workaround as it’s unfortunately not currently natively supported. 3rd hypothetical way is to create even more complex mechanisms of filtering & redirecting data which would be increase a level of complexity to just introduce but also maintain (unless you'd already have something similar existing in your infrastructure) and I wouldn't recommend it.
please does anyone know if it is possible to restrict who can change state of the work item on a state by state basis?
E.g. that only limited people can move item to Done, another group can mark item as removed, etc.
Thanks
You have to use custom rules in your process. Check the following links:
Add a rule to a work item type (Inheritance process)
Restrict state transitions
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
Feature cycle time is a very important metric, but in ADO there doesn't seem to be a way to get the State of a Feature to automatically update when the first story moves into Active (or the last child is closed). Does anyone know of a way to have this happen?
No, that will never happen. This area for custom application and solutions. You can try the following:
TFS Aggregator
Write your own solution through rest api: Automation of state changing for Azure DevOps work items based on states of child work items
Use additional solutions: Automation of state changing with Azure Logic App
When I try to add new completed state to user story or task in inherited process of my azure devops project, I get the following error :
VS403093: Team Services currently does not support changes to
'Completed' category. Choose a different category.
I have looked all over the web and it seems like this is the desired behaviour as mentioned in this link, which I think is very weird.
Are there any workarounds?
I want to create a Done state for my work items, and I think that it's dumb to keep only the closed state for all completed work items since Completed fits better with tickets not with user stories in my sense...
As mentioned below, I could modify all the states except for completed
Any help would be appreciated.
Like you said, at this time Microsoft not allow to change or add states in Complete category.
From Microsoft Docs:
Completed: Assigned to states that represent work has finished. work items whose state is in this category don't appear on the backlog and do appear in the last column of the Kanban board. Note that you can't modify states in this category nor can you add states to this category.
If you want the state "Done" you can use Scrum template (in Scrum the complete state is Done and not Closed).