search

MethodsAndPractices / vsteam

PowerShell module for accessing Azure DevOps Services and Azure DevOps Server (formerly VSTS or TFS)
https://methodsandpractices.github.io/vsteam-docs/
MIT License
445 stars 155 forks source link

Extend set of -WorkItemType commands #361

Closed jhoneill closed 1 year ago

jhoneill commented 3 years ago

PR Summary

PR Checklist

jhoneill commented 3 years ago

Scrub that comment, Azure Devops pipelines were misbehaving yesterday PM, and are back to normal now.

DarqueWarrior commented 3 years ago

All the code around $env:TEAM_PROCESS makes me very uncomfortable. If you want to set a default for it use 

$Global:PSDefaultParameterValues["*-vsteam*:ProcessTemplate"] = "yourTemplate"

ProjectName is an exception because it is used by 90% of the functions. ProcessTemplate is not.

SebastianSchuetze commented 3 years ago

@jhoneill one request: Could you tell us when your PRs are finished? You seem to be able to work on it in your work time. We are not. When we review something and you keep changing the files and adding things, you really make it hard for us to be willing to check the changes no matter how good they are.

Please finish the PR to a state where you not change anything anymore until we find the time to finish it.

jhoneill commented 3 years ago

@jhoneill one request: Could you tell us when your PRs are finished? You seem to be able to work on it in your work time. We are not. When we review something and you keep changing the files and adding things, you really make it hard for us to be willing to check the changes no matter how good they are.

Please finish the PR to a state where you not change anything anymore until we find the time to finish it.

Understood . This is the foundation for additional work for a stack of other stuff and goes back to what I put in in #320 which I posted 5 months ago today. I can freeze this branch and put things which are logically part of it in another branch. But then if you say "wouldn't it make sense to do X" I'd have to say well yes, that's in the PR which I put in after this one to fix stuff which you still haven't merged. And obviously that would be frozen, so it might be "it's in the follow-up to the follow-up PR".

As well 3 new and two changed commands here (making Process information more accessible, and commands to add / change work item types) I have 2 for Add and change Process Templates and 5 for Process and Work Item behaviors (boards), and 2 for team settings which relate to behaviors - 9 in all in #364 which depend on this. 5 which relate to the states you can set a work item to in #362 which also depend on this. 7 which relate to picklists, fields, and adding fields to a work item type in plus 6 new classes for picklists and fields in #370 which again depend on this. And about 10 more which handle layouts on Work Item types. (Adding/Changing/Removing Pages, Groups and controls) which depend on #370. So a couple of dozen commands in five branches.

Now... Doing the layout stuff I found every add and set might be working on a WorkItem type which was copied into the process template at creation, before changing it , an inherited type must be created because the original is locked. I'd copied the same code into multiple functions. So I pulled it out as Unlock-WorkItemType and pushed it down into this branch (and removed the duplicate code in four of the five branches) I could wait for you to finish this one, #362, #364, and #370; and then send a PR to that (and make a more complex set of dependencies). Or I can use the delay to put things right...

jhoneill commented 3 years ago

@SebastianSchuetze

@jhoneill one request: Could you tell us when your PRs are finished? You seem to be able to work on it in your work time. We are not. When we review something and you keep changing the files and adding things, you really make it hard for us to be willing to check the changes no matter how good they are.

I'm calling this branch "Frozen" now.. I will only allow fixes for something to badly broken and to wait for a future PR. I've been using some quiet time at work. We did a check and found we have over 1000 Azure devops organizations linked to our Azure AD: every contract creates an AzDO org and sets things up differently from every other project. If you transfer between contracts you have to learn how the new one uses AzDO and management can't get usable data because everyone calls custom work item types different names, creates custom fields for the same purpose with different names and units. The end goal for all of this is "Azure DevOps as code" and projects which look very similar.

Since all the other things I'm sending you are sub-branches of this one, it would be great (from my point of view) if you could progress this. I will confirm when the other ones are properly "frozen" as well. If I (and other people) seem to be taking the use of your personal time for granted then we owe you an apology. Hopefully there's some comfort in people seeing your work and assuming you must be working on it full time :-)

DarqueWarrior commented 3 years ago

@SebastianSchuetze

@jhoneill one request: Could you tell us when your PRs are finished? You seem to be able to work on it in your work time. We are not. When we review something and you keep changing the files and adding things, you really make it hard for us to be willing to check the changes no matter how good they are.

I'm calling this branch "Frozen" now.. I will only allow fixes for something to badly broken and to wait for a future PR. I've been using some quiet time at work. We did a check and found we have over 1000 Azure devops organizations linked to our Azure AD: every contract creates an AzDO org and sets things up differently from every other project. If you transfer between contracts you have to learn how the new one uses AzDO and management can't get usable data because everyone calls custom work item types different names, creates custom fields for the same purpose with different names and units. The end goal for all of this is "Azure DevOps as code" and projects which look very similar.

Since all the other things I'm sending you are sub-branches of this one, it would be great (from my point of view) if you could progress this. I will confirm when the other ones are properly "frozen" as well. If I (and other people) seem to be taking the use of your personal time for granted then we owe you an apology. Hopefully there's some comfort in people seeing your work and assuming you must be working on it full time :-)

I appreciate all the support but this is not my full-time job. Man, I wish it was. I am going to try and devote more time to it going forward but I appreciate your patience.

DarqueWarrior commented 3 years ago

I will be returning to this PR soon. I used the $env:XXX for defaults in my last PR so I will work on changing the way the current defaults are implemented to match.

DarqueWarrior commented 3 years ago

Hey, @jhoneill would you be open to a Teams meeting to work through this PR? There are some design decisions I want to make sure I understand. I want the contributions but I also want them to be consistent with the rest of the module. I am open to being convinced to change the rest of the module if that is the correct move.

SebastianSchuetze commented 1 year ago

gonna close this PR since it is too old and actually too much changes to review. If reopened then it must be made sure that no PR is directly dependant on the other. But thanks for the effort.