Trying to use OpsHub (free version) to migrate from on-prem TFS to VSTS. It is failing on a work item with the following error:
com.opshub.exceptions.eai.EAITFSPollerException: OpsHub-012310: Error
occurred in getting link/attachment information for WorkItem 46906
Revision 1. Caused By OH-TFS-Connector-0051: Operation failed
getLinkInformation. Server Error : TF26198: The work item does not
exist, or you do not have permission to access it.
I am able to access the work item. I did see the work item had 3 associated work items and I verified I could open all of those as well.
Any suggestions? I did get this with a few other work items and I purged them. I would like to know the cause as I anticipate running into this issue again and the process of manually removing the work items is costly as I do not have a list of all the problem work items. I have to resume the migration and wait for it to error.
Update: I have been able to identify the culprit. This work item is linked to another work item in a different project. Surprisingly I can't see that item even though I have collection admin. I'll keep working on it. I know the linked work item exists.
As Justin confirmed himself, the issue was Access Permission. The user through which the migration was running, could access the WIT in question and it's links. But could not access the linked WIT (which was from another project). Providing the permission to the migration user, by making him the 'Project Collection Administrator' solved the issue.
Related
I use VSTS and tfs aggregator to update parent fields when I have some changes in work items, and every things work fine. Now I want to update parent field when I delete the work Item. and I get the error:
Exception encountered processing notification: TF26198:
The work item does not exist, or you do not have permission to access it.
Stack Trace:
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.LoadWorkItemFromRowSetInternal(Int32 rev, Nullable`1 asof, IWorkItemRowSets witem)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem..ctor(WorkItemStore store, Int32 id)
at Aggregator.Core.Facade.WorkItemRepository.GetWorkItem(Int32 workItemId)
at Aggregator.Core.EventProcessor.ProcessEvent(IRequestContext requestContext, INotification notification)
at Aggregator.WebHooks.Controllers.WorkItemController.Post(JObject payload)
It makes sense when I delete the workItem, there is no work item I could access via it to parent, But is there any way to get the deleted workItem's parent? any idea?
There is no simple answer to this.
We added support for the deleted event at some point, but Aggregator receives the event, after TFS has marked the work item as deleted. The API we use filters out those objects IIRC. The only useful piece of information you have is the ID of the deleted work item. Using PreviousRevision you might be able going back in time, but I haven't tried.
Source code is available and PR are always welcomed.
Update:
You can't do this.
The error is very clear:
The work item does not exist, or you do not have permission to access
it.
When you delete the work item through command, all information is also deleted. This permanently remove work items from the data store. A permanent delete means all information in the WIT data store is deleted and cannot be restored nor reactivated. You definitely could not query and update the deleted Work Item's parent.
Even if the work item exist "somewhere", then you don't have permission to open the work item, and also you can't query information about it. It's a bit of chicken/egg. Take a look at this similar question: TFS API: How to check if a work item has been deleted or is non existent on the TFS Server? (not if it is accessible)
I am using TFS 2013 and I am trying to customize a workitem template using the ProcessEditor form (I also tried to do the same using the editing and importing xml file),I am trying to add a "ReadlOnly" rule to a field only for some new TFS global group, so I added the new Group and after that I could see and select the newly added Group from the "For" dropdown but when I am trying to save the changes I always got the error "The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account" I googled the error and found a suggestion here http://www.databaseforum.info/30/943697.aspx that it may be a caching issue so I waited days for this and restarted the client and the TFS server machines but without any luck although I can use old created groups without any issues however if I renamed one of these old groups then tried to use it I still got the same error message no matter I add the new groups as a member of any other group.
First, make sure your TFS admin not have done any security changes (adding account or groups or permissions) for your account.
If not, you could try below two possibilities to narrow down the issue:
Check if you had added a field that contained backslashes as values
and TFS may interpreted it as user account. For example if your field
contained a list of suggested values that looked like this: Category
1\Subcategory 1
When you add a value such as
<TRANSITION from="Resolved" to="Complete" for="[project]AllTesters" not="[project]NewTesters">
</TRANSITION>
you should not extend the project to [your project name]AllTesters, should just use [project]AllTesters
For more detail info and ways, please refer below similar issues:
TF26204: The account you entered is not recognized
Experiment on Limit AssignedTo field of WIT to Team Members
Warnings TF26171 and TF26204 during WIT import
Here is the thing, I left it for couple of days and when I returned to it I found everything is working like a charm, I added now some new groups and couldn't see them so I guess I will wait some days for it to work!
the issue was the service agent job that was responsible on syncing the AD changes with the tfs was stopped, everything worked fine when I started it
I'm getting this error while trying to access Administration Page of my collection:
Administratio Page ERROR
I tried upload TFS.Configuration database, but no success so far.
This is the results of my sql selects:
SQL SELECT
According the error info VS402375: Can't find the process associated with team project 'xxx'. Contact support to resolve this error.
It looks like the process template (which you used for the project) is missing in the team project collection database.
A solution is restoring your back-up database, which may do the trick for this issue. Daniel is right, it's highly not recommend to modify TFS databases yourself.
Another solution is manually changing the templateID to match what your collection. More detail steps please take a look at bmonwai's answer in this similar question.
I know this is a really old post, but this also occurs if you have Extensions installed and then move from one database to another (backup/restore)
When you are attaching the collection, this would have given you a notification that is has dependant extensions. If you ignore this and continue, when you try to get to the admin page for that collection you can get this error as well.
I would recommend either installing the dependant extensions OR prior to detaching the collections at source, ensure you remove/uninstall the extensions.
Usually, installing the required extensions can solve this.
So, we are using TFS 2012 RC and have modified the work flow a bit for a regular task item by adding a few custom transition states.
When updating tasks though Visual Studio 2012 RC, everything works fine. I can move through all the states without any problems. However, when updating the task through TFS Portal, either by dragging the item on the board or opening the form and changing the state using the pulldown, I get the following error: "TF237165: Team Foundation could not update the work item because of a validation error on the server. This may happen because the work item type has been modified or destroyed, or you do not have permission to update the work item."
This ONLY happens, however, when moving to the Done state and nothing else. All other states work fine.
So, I'm not sure what that means since it works fine in Visual Studio. What would be helpful if I could see the exception or more information somewhere, but I don't know where these validation errors are stored.
Any help would be greatly appreciated!
The issue was with the work flow. The transition was setting a field that was conflicting with the state also changing the same field.
In my case there was another issue.
The problem was that the field had a trailing \r\n in the data being sent down by the server. I believe the client javascript OM was removing this which makes the field dirty even though it’s read only.
Workaround was to make the field read-write instead of read-only. Then I set back it to read-only - and now it works.
Micrsoft promised they may fix it in next release.
In my case, on TFS 2013 U5 I had changed my TFS Profile DisplayName so that it did not match my ActiveDirectory DisplayName. I could not edit or create anything until I changed the DisplayName back.
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.