I am using TFS API and I need to check if a workitem has been deleted or if it does not exist.
If i use WorkItemStore.GetWorkItem(Int32) and pass the Id of a deleted Work Item here, then the message says that "The work item does not exist, or you do not have permission to access it."
I need to check only for the deleted condition and not the inaccessible condition.
I've searched in the API but could not find any way to check for it.
I need this because I need the list of workitems that have been deleted.
In my program I have a list of some existing workitems. I then need to check if any of these workitems are deleted but I don't have to care whether the logged in user has permissions to see it or not.
And in my program I need to be absolutely sure that the workitem has been deleted because I have to make some irrevertable changes for every deleted workitem from my list.
You can't. If you don't have permission to open the work item, then you can't query information about it. It's a bit of chicken/egg. Even when you do have permission, you cannot be sure a workitem was deleted, or has not yet been created.
I'd run your tool as a service somewhere under a user that has project collection level permission or server level permissions to read the work items. You could also implement your own webservice which does that and then use the outcome in your tool.
Related
I want to raise jira incident with approvers using rest api. I am unable to do so as i am getting below error:
customfield_XXXXX can not be set. it is not on the appropriate screen
I assume I can not add approvers while creating incident. I am using curl to raise incident.
If I try to manually create an incident, I don't get any options to add approvers, but once jira is created, I can see the option to update approvers manually from web ui.
Is there a way I can update an already raised incident with the correct approver name?
The Jira version we are using is v8.5.5.
The reason you cannot add approvers when creating the issue is that the approvers field does not exists on the screen which assigned to the create context of the screen scheme which is assigned to the incident issue type in the project's issue type screen scheme.
You are probably able to add approvers once the issue is created either because the field exists on the screen assigned to the edit context of the screen scheme, or because you are setting it on a screen during a workflow transition.
If you have site administration permissions (or maybe just project administration permissions depending on how the site is configured), and it makes sense in the context of your use case, you could add the approvers field to the create screen.
To update the field after the issue has already been created, without making any config changes, is dependent on how you are currently able to set the field. You will either be able to make an API request to directly update the field, or you will need to transition the issue through whatever transition currently allows you to set the field, again via API.
We have an enterprise customer that we have delivered a system for. It is part of the agreement for us to supply them with the source code of the latest release. We are using TFVC on TFS online, and we thought it would be easiest to give them access to our Main branch. But I have difficulties with only allowing them to access the code and nothing else. The user I am testing with, can see too much: I.e. things like dashboard, current team members etc.
Is it possible for me to only expose code from the Main branch and nothing else to an external user?
Giving access to TFS Main Branch out of Organization (AD) is not advisable considering security.. Instead consider giving source code into zip format there are lot of large file sending (FTP sites) are available..
Still for your request of restricting access to user have a look over this
https://www.visualstudio.com/en-us/docs/setup-admin/restrict-access-tfs
you can consider replicating your part of source code into separate stream and give reader read only access to that stream.
Hope this helps... :)
Refer to these steps to set the permission:
Add user to your VSTS (Basic)
Remove this user from all group if you added
Go to admin page of a team project Version Control (Setting > Version Control)
Select a folder/branch
Click Add > Add User to add that user
Select the user that you added
Set Read permission to Allow
Go to Security page (click Security)
Click Create group to create a new group
Set View project-level information to Allow and deny other permissions for this group
Click Members of that new group
Click Add to add that user to this group
After that, this user can access the code (Just the folder/branch the user has the read permission) on web access (Code > Files).
We had a person leave our company and their windows domain account for Active Directory was deleted. They have since come back but have been given a different windows domain account user name. Now when we attempt to assign them tasks it's always associated with the old account. I assume this is because the name is still the same and TFS is doing some kind of duplication check. I've tried removing cache and have verified that the Team Foundation Server Periodic Identity Synchronization job is running properly. I can also see the old active directory account show up when attempting to Add a windows user or group via the dialog along with the new Active Directory user.
What's strange is this user is not showing up as a member of any groups in TFS for any of the Team Project Collections. So why are they still showing up in the [Team Project Collection]\Project Collection Valid Users group?
Seems the main issue is deleted users still in "Assigned To" List. First try to throw down the issue.
If you are using VALIDUSER rule, it contains all valid users in TFS. You may check collection level Project Collection Valid Users group, you may need to check every group to delete the user. And use TFSSecurity /imx command to display information about that group, thn delete the user from right group.
After delete the old user, you need to try to let TFS sync with Active Directory, for detail steps, you can refer to:
Force TFS to sync with Active Directory
Active Directory Groups not Syncing with Team Foundation Server 2010
I created a tfs group that would work on a specific project located in a collection. Now we're using work items to track bugs etc, but that group doesn't have access to those work items via the Team Web Access portal. I don't want this group to have access to all the projects in the collection, just the one they are working on. But i need them to be able to access work items that come up.
Currently when they access the Team Web Access portal, they get message indicating there are no accessible team projects in this team project collection.
if they can access their code in the collection already, how come they can't see the work items, and how can i change that, but still limit what they see?
Ok, found what i was looking for after some time. for the benefit of the community here is where that hidden security setting is done.
For the new group, i needed to go under Team/Team Project Settings/Area and Iterations!!!!
Yes, this silly place to but a SECURITY button. If you go in there, click the security button on the bottom of the dialog, you will then see ALL the WORK ITEM related permissions.
EDIT work items in this node;
Manage Test plans;
View this node;
View work items in this node.
I needed to check all of these to ALLOW.
Again, seems like a stupid place to put these settings, than with all the other security settings via TEAM Project Settings. I hope they had a good reason for that.
They will need the View collection-level details permission added to their group (at the collection level). By default, the Project Collection Valid Users group has these permissions, so you can just add your group as a member of the valid users group.
I have created a couple of Document Lists on our SharePoint 2007 portal. I then checked in the page and submitted for approval. The approver aproved the change. However, all the previously created document lists have a drop down list for each uploaded document with options like: View Properties, Edit Properties, Manage Persmissions etc. But the one I created does not have that drop down list when you hover over the documents. The person who approved the change is not able to see those options either. I am pulling my hair on this one.
A custom permission set may have been applied. Can you also not delete the list? If you go into the document list, do you have the settings option?
If possible, ask someone with Site Collection Administrator or Farm Administrator permissions to log in and view the permissions on the new list. This should reveal if there is something out-of-whack with that list. If it's inheriting permissions from the parent and all the other lists are as well, and you have access to the other lists but not this one, well...this just shouldn't happen.
Can you find out what list permissions look like?