In order to make sure that obsolete versions of the product aren't selected for a work item's iteration, I would like to be able to cloak certain iteration nodes from view, when opening a new work item.
For example, if the current production version of my site is 3.5, and 3.6 and 4.0 are in development, I want to make sure that when a user creates a new work item, versions that are older than 3.5 (e.g. 3.4, 2.7) will not be selectable.
I can conceive of a way to do this creating a custom control, but I'd like to avoid those, as they'd require development of both desktop and web controls, and would have to be deployed to all users.
Any ideas, directions, or just an "it can't be done", would be appreciated.
Thanks,
Assaf.
I am not sure if you can hide it as a selection.
However you can set the security for "Edit work items in this node" to deny and they will not be able to save workitems with the area or iteration selected.
I'm 90% sure it can't be done.
I haven't tried this myself:
Along the line of access control, I believe if you deny "View this node" permission on a user then she will not be able to see this node at all. Be aware that she will probably not be able to see the work items that are under this node, but I guess you are fine with that.
Another thing to note is that this solution might not work with Administrators (because if all Administrators are denied view permission and cannot see the area path then it's lost forever).
Related
we are using Jenkins LTS 2.150.1, Is it possible to hide the nodes/slaves list (by default at the lower left side of the screen) from "regular" users (i.e - not admins).
Is it even possible?
Am I missing something?
I tried:
looking in the configuration of the server, couldn't find any "switch" or anything of that sort to hide it.
looking for a plugin to do that, but couldn't find anything that isn't changing the entire "look and feel" of the basic jenkins theme.
Seems to be that this feature is not added yet. See this ticket.
I have an old setup with a tfs2010 and sql2008 and the current Collection is holding 3 team Projects. Now i want to create a new team project but for some reason i cant. it seems that it has something to do with the SQL Reporting that dosent excists. i get an error TF218027.
Ive been going through the setup and im wondering a bit
What exactly does the TFS use the reportServer for (MSDN dosent seem to want to tell me)
is there any way to create a Team project without the reporting
Will it damage my excisting data if i create and connect to a new sql reportServer
Hope someone will take the time to give an answer
thanks.
I have already tried the different approtaches discussed on different threads and im primarily looking for information on the 3 questions written above
Try the steps below:
In browser go to: http://application-tier/Reports/Pages/Folder.aspx
Press Folder settings button in the toolbar
Press New Role Assignment button in the toolbar
Specify user name in Group or user name field, check Content Manager role and press OK.
So for the people that actually read the question the answer is.
Keeps track of agile work progress
yes and its actually easy. go to the reporting service and stop it and then tell TFS not to report under reporting
Since it was never running the answer here is No
After upgrading to TFS 2015 we are seeing all users in the collection being displayed as options for the Assigned To fields of a Work Item.
In 2013 we had set an ALLOWEDVALUES rule set to [project]\Contributors. It would restrict the list in the drop down to only the values in that group.
Now the drop down shows everyone and only complains if you try to select a user from the complete list that is NOT in the contributors groups.
How do we get the old behavior back?
In many organization, the work item type is shared across many teams. The old dropdown was long and was cluttered with people you would never assign a work item to. We heard a lot of requests to make assigning to people a much better experience.
We have changed the work item control to a MRU control so people you care about most show up immediately. And there is a "search more" option to find people which are not in the MRU yet.
We are aware that it is not possible anymore to restrict the list with the rules you define on the work item. It was an explicit design decision, and the rule is still enforced on save as you indicate.
Ewald Hofman - TFS Program Manager
You can follow below steps:
Creat a collection level group. Team Explorer-->Team Project Collection Settings-->Group Membership-->New-->Group name: MyTeam--> Double-click [your collection]\MyTem-->select Windows User or Group-->Add-->add users
Create a "Issue" work item type. Tool-->Process Editor-->Work Item Types-->Open WIT from server-->Copy an existing work item type and change the name as "issue".
In Field tab, double-click Assigned To-->Rules-->New-->ALLOWEDVALUES-->in ALLOWEDVALUES window, click New-->in List Item Edit window, enter [Project]\MyTeam-->OK, then save this work item type.
For test:
4. Create a new "issue" item, in Assigned To drop down list, you can only see the users you add in MyTeam.
I have created a Basic MSI Installer using InstallShield 2014 for a server/client program and have to hide features dynamically based on the License Key of a database that is installed prior to our Server app being installed. I have created conditions for the features that need to be hidden, setting the InstallLevel to 0 if they are not licensed and 1 if they are licensed. I am getting the license key after the SQL Login dialog (because the installer wouldn't know what database to look in otherwise) but conditions are evaluated during the CostFinalize action, which runs before the dialogs are created. So after I get the license key and run some other custom actions to determine the availability of each feature, I call the CostFinalize action before the CustomSetup dialog is shown.
I am getting the correct behavior for the features that need to be shown, and you can select or deselect said features in the dialog, however, when the installation executes, the selected feature is not installed....and the log file says that the feature is not selected for install, even though the user clearly selects it. Why would this be happening? Is there another approach to hiding features dynamically (I have tried the FeatureSetData function in an InstallScript action, but to no avail)?
Also, after I added the conditions to the features, whenever I try to uninstall the program from the Programs and Features app, I get an Error 1606 Could not access network location. It's like the registry key gets messed up when there are conditions on the features...Any help would be greatly appreciated.
I found the problem...If you set the features InstallLevel to 0 to start with and have a condition that sets it to something greater than zero, then it will not install the feature, regardless of whether it's selected. If you invert this logic and start with the features InstallLevel set to 1 and have a condition that changes the installlevel to 0, it will hide or show the feature AND it will be installed properly. This also caused the error 1606 I was getting on the uninstall...
Also, if anyone ever has components that get installed that aren't supposed to be installed, then you might try switching the Dependency Checking to none. For some reason, the .NET dependency check that InstallShield does causes certain components to install all the time, even if their assigned feature is turned off. Hope this helps someone in the future.
The CostFinalize can also be run by a dialog to refresh the feature list. Here are the steps:
In the Next PushButton of the SetupType Dialog, create a new item at the top.
Event: DoAction
Argument: CostFinalize
Condition: 1=1
In my case, I was hiding a feature based on a previous dialog and needed it to reevaluate conditions in the Program Feature.
Condition: Level:0 GLOBAL_VAR=0
Condition: Level:1 GLOBAL_VAR=1
TFS stores information about who created or who activated a work item and for some reason checks its validity whenever the work item is modified.
When a user is deleted from active directory or renamed in active directory, all work items even slightly has connection with the user can not be modified. Usually the error message is something like ...
TF20015: The field 'Activated By' contains the value 'blah blah blah' that is not in the list of supported values.
I've found a blogpost which recommends tweaking the TFS database, which is something not supported nor recommended by Microsoft.
What can be done to resolve this?
Thanks...
e-mre
Caveat: I'm not sure that this will work, and right now I'm not in a position to test it. However, I've had success with this approach on some other fields.
If you use the TFS Power Tools to edit the work item type definition, you should be able to change the Activated By field's rules and add an ALLOWEXISTINGVALUE rule to it. This might allow you to save those records when the AD name changes.
We've used this with some success with the Assigned To field.
I've seen this behaviour. It occurs if someone who activated a work item is removed from Active Directory (leaves the company) or if they change their name (gets married).
It's simple to fix, you just need to change the work item status from Active to Pending then back to Active this will change the "Activated By" field to the person chaging the status and the problem will be resolved.
Are you using TFS 2008? I seem to remember that this issue is fixed in 2010 (but I might have dreamt that)
If you have a lot of work items this blog might have a solution that helps automate the fix.