I have an old instance of TFS 2015 that was installed with the DefaultCollection for the instance. We are moving to a 2017 TFS instance now that has a Named Instance so we can't just import the old TFS into the new because there is not DefaultInstance and there won't be one (according the to the SysOps that run the server). So I connected to the 2015 instance and ran a query to pull down all the work items and history into an excel database. However, when I try and connect to the 2017 instance to Publish I keep getting the error:
The reconnect operation failed because the team project collection you
selected does not host the team that the document references. Verify
that you selected the correct team project collection and try again.
So how can I pull the DefaultCollection from the old 2015 server and publish it to the new 2017 TFS server under a different Collection Name?
Thanks.
I finally figured out how this is done so I am posting my steps in case someone else needs to know.
Created the queries in the old version of TFS (in my case 2015). In my case I created a "Tree of work items" query type, and set the Work Item Type value to Feature. And Set the State to any.
In the "Filters for linked work items" set the Work Item Type value to [Any]
In the Filter options, set the option in the dropdown to "Match top-level work items first" and the Type of Tree to "Parent/Child"
Run the query and look at the results. The minimum columns that I found to work are Work Item Type, Title, State, Area Path and Iteration Path
Run the query in Excel to set the results. Copy the results from the excel worksheet. Open a new instance of Excel, and connect to the new instance of TFS. Select New List, then change the type to Input List.
IMPORTANT!
Make sure the columns match between the two workbooks. If you have a Column called Title 1, Title 2, Title X then click the title column and click "Add Tree Level" to create the same columns.
2. Paste the results into the new worksheet. Change all the values in the "State" column to "New". Any other value may not import. Make sure to update the Area Path and Iteration Path to the correct values.
The minimum columns I found that do the correct import are:
1. Work Item Type
2. Title
3. State
4. Area Path
5 Iteration Path.
When I tried to import the Epics with children it would constantly fail. So I did the export with children from the Features down to stories and tasks/bugs and it worked.
Related
I am freshly new to userforms and trying to further streamline an already VB "automated" process through a selection of possible reports I validate on a report-to-report cadence.
The process includes pulling reports from two separate folders, the old reports and the new reports, then validating them per report (by-country). I have this process down in VB script, but I have to constantly change the dates according to the "last pull date" and "new pull date", the countries affected, and the project I am working within.
The idea would be to type in the dates, check off what project I am working on, and then check the countries I will be working within. Below I have outlined the steps to complete.
Select Project (Only a single selection allowed)
Select Country Report (Multi-Selection)
Type last pull date to navigate to last pull directory folder format.("yyyy-mm-dd")
Type new pull date to navigate to new pull directory folder format.("yyyy-mm-dd")
Example:
Projects-- in single selected listbox
A , B , C (I choose B)
Countries -- can be a multi-selection listbox or can be checkboxes
AR, BR, CA, SA, WD (I choose BR, CA, & WD)
Last Pull Date -- typed in
2019-06-23
New Pull Date -- typed in
2019-11-07
--> Question: How do you assign the variables selected in steps 1-4 to be entered dynamically into a subprocess? The list i believe i can get down, but how do I assign the check list to a variant and then to a variable within a subprocess to be executed?
I am having backlog in TFS 2018 and I am using default template provided to create the tasks.
The template is having the 'Activity' drop down, while selecting the 'Activity' it is also renaming the Task Title. It is ok if I am adding the task using TFS.
Now, I am using the Excel to create the tasks in the user story.
Only problem is whenever I publish the list, it is renaming the Title of the tasks with Activity name.
For example, If I publish the following list, "My Task" will be renamed with "Requirements- Review" (Value in Activity Column) in TFS board under "My Userstory".
Is there anyway to disable this behavior while adding tasks using the Excel?
As per my understanding both Titles are required as it is creating the
Parent Child relationship. In Excel I am selecting Title 1 and
clicking on "Add Child" and it is creating Title 2 column.
Actually we do not use this kind of way to add a nested list of work items( Parent Child relationship)
For example, you should first convert your flat list to a tree list by adding a tree level.
Enter titles for backlog items under Title 1 and for tasks, under Title 2. Also, select the corresponding work item type for each. Here we specify Task.
Publish your worksheet and the ID 95 is new created through Excel. In the background, parent-child links are created for each task listed.
As you can see in web portal, the new create task is list properly and title do not change and activity is also right.
More details please take a look at this official tutorial-- Bulk add or modify work items with Excel
I am setting up a SharePoint app/list to house my business team's project proposals for the next budget year. I've created a custom content type (named CostProject) that has several columns in it that describe our cost projects.
Because we plan on using this process for years to come, I'm envisioning a structure where CostProject is the generic content type, with sub-content types for each budget year (2018 CostProject, 2019 CostProject, etc.). So I created another custom content type (named 2018 CostProject) that inherits all of the columns from CostProject.
Now I'm trying to create a list of all of these cost projects. So I added a new app (type: Custom List) and named it ITDD Cost Projects. I went into list settings >> advanced settings and checked the option to "Allow management of content types." Back on the list settings, I scrolled down to the content types section and clicked "Add from existing site content types."
This brought up a form where I could select various content types, so I selected 2018 CostProject from the available content types and clicked "Add >" then clicked "OK." After clicking OK, this is the error I get every time:
"The formula cannot refer to another column. Check the formula for
spelling mistakes or update the formula to reference only this
column."
Thinking this might have something to do with the syntax of one of my calculated columns, I went back the CostProject content type and removed all of the calculated columns (copied their formulas, etc. into a document so I can come back to them later). However I still get the same error message every time I try to add the content type to the list.
Any idea what I'm missing here? I'm pretty new to SharePoint so perhaps it's something basic--any help would be greatly appreciated!
THANK YOU!!!
So for the sake of people not reading comments. When you encounter an error which states that:
The formula cannot refer to another column. Check the formula for
spelling mistakes or update the formula to reference only this
column.
You should check your validation formulas on columns.
It may occur in different situations, but the core issue is that field cannot be added to list:
Here is reported bug when creating list from template and this is possible workaround.
I need to update List A from a form submitted in List B, where B.username = A.username. I am used to using SharePoint 2010 Enterprise and some of the advanced tools that go with that, but right now I am stuck on 2010 Foundation.
I don't know if I'm just having a brain pfft or something, but I can't make it work. Is this a limitation of Foundation? In the workflow editor in 2010 Designer, I can say update List A with a value from List B, but somehow not submit a where clause. Can anyone help?
What I'm actually trying to do is have a list of all users on the network and the form from List B just updates the "Accept" or "Decline" by the user's name in the first list.
Any help would be appreciated.
Assuming this is one-to-one relationship - that is, the WF triggered on the item in List B would only ever update one item in List A - when you configure your "Update List Item" action within the WF and select a "List" other than 'Current Item', a section will appear at the bottom called "Find the List Item" that will allow you to define how the WF will find the item in List A to update.
See here:
Bear in mind though, when using SharePoint Designer, you're limited to one-to-one relationships, and the only 'where' clause you can apply is an equals filter whereby some value you have (be it from the current item, a WF variable, an initiation parameter or a static value) is compared via equals operator to a field in the remote List (i.e. your List A). Should you define a clause that could result in more than one match - again, your WF on List B cannot trigger an update to 'n' items in List A - you will see this warning:
Caveat: all these conditions only apply when creating a WF via SPD; if you have access to Visual Studio, you can use it to create & deploy workflows that do support updating multiple items in a remote list based on a single WF being triggered, querying the associated items through something other than an equals, etc.
I got a question about the behavior of lookup fields when importing data. I wonder how the lookup fields behave when the list they point to is being replaced/imported. To explain the issue, I will provide a quick example below:
As example, assume we have these two sharepoint lists:
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
In my scenario, the Products List contains production data on the production Sharepoint platform. It is filled with data by the business users.
However the Product Types list contains rather static data and is maintained by the developer.
Now after a development cycle, the developer wants to deploy his new webparts and his new data (product types list). The developer performs the following procedure:
On the dev machine: Export "product type" list using stsadm
On the production machine: Delete all items in the "product type" list
On the production machine: Import the "product type" list using stsadm
This means we basically replace the "product type" list on the production server while keeping the "product" list as it is.
Now the question:
Is this safe? Will the lookup references break under certain circumstances?
Any downside of this import/export procedure?
What happens if someone accesses a "product" during the import? Will the (now invalid) reference clear its own content (become a null value).
What happens if the schema of the "product type" list changes (new column)? Will this cause any troubles?
Thanks for all feedback and suggestions!
Update 1
The imported "product type" items have the same IDs as previously deleted ones.
Update 2
Started a bounty to get some more feedback/opinions.
We have had this exact same scenario before. This is a little tricky, depending upon how you will approach it.
1) Delete and Recreate Product Type list through UI
If you delete and recreate the lookup List(Product Type in your case) through UI, then you will lose the connections because the List's id GUID will change upon recreation. So do not go that route.
2) Delete and Recreate Product Type through a Feature
If you had created the Product Type list through a feature.xml file using the <ListInstance> element, then if you delete that list and then recreate it using the same feature (basically Id attribute of ListInstance remains the same, number of list items, i.e. the number of <Row> elements, may change), the association would be maintained. So if you were adding 5 more product types, then if you had created the list using a feature, you could just delete the list and provision the new one using the same feature with extra info for new items and everything would just work!
As a side note, this is the better approach because if you have to do the upgrade on a lot of servers, then rather than doing list export import via stsadm, feature deactivation and activation is a much more recommended solution. This is how we did it.
3)Deleting all list items from Product Type and adding new ones (list is never deleted)
If you are linking the lookup field (in Product List) to the ID field of the lookup list(Product Type), you have to remember that ID is auto-incrementing, so if you delete all items and then add new ones, then their ID's would be different. Say you had 5 items with ID's (ID field is not shown in UI while editing in Datasheet view) 1-5 in the list. If you delete them and add new items, their ID's would start from 6 and not 1 again. So if your lookup field had link to the item with ID 1 in it, then this method is not going to work because there is no item with ID 1 in the Product Type list anymore. So you might want to really try this out before going to production with this method.
4) Editing the list in place
If the list is not extraordinarily huge, and you only have to make this change to one or two instances, could you not just edit the list directly in the datasheet view on the prod server? When editing in datasheet view, do not delete the item, but just overwrite the values of its columns. And you can add more items if you want. This will make sure your ID's are valid.
I have mostly talked about adding new items to the list. Now if you were deleting existing items, then your lookup fields will be affected because assuming you linked the field by ID, the ID is not present anymore since the item has been deleted. Basically, any method you use, maintaining your ID's is critical.
Now regarding your doubts/questions:
I am not too sure about stsadm export import for a list (never done it myself), but stsadm can be tricky as some operations will work on certain scopes only. So you better try out your exact scenario on a dev env.
What happens during an import is tricky again depending on the exact timing. I am sure SP has its own concurrency mechanisms, but you cannot have a definitive answer as it might probably be different based on the stage of the import. If possible, recommended approach is to do the import during a planned downtime.
Regarding changing schema of the list, a change in the schema of a list will not affect the existing list instances (for the most part). If you do this through UI, I believe SP makes changes to the content DB directly. I am not certain how you intend to do this, but if you were to add a column to an existing list using a feature, the way to do this is during feature activation by adding a new content type to the list and adding your new column to this content type. This way you add the column but do not affect the existing list items.
Good luck...
There are two components to a particular lookup: the field, and the field value. The field value only contains the ID of the item(s) it refers to, and the display field. This information is meaningless without the field, which specifies what list to look at and what field to use as the display field.
The primary reason that a Lookup will break occurs on the field scope: either the list it referred to no longer exists, or the list does not contain the required field. These would generally happen if you deleted and recreated the list, but you aren't doing that. If you do break a lookup's list reference, then the only thing you can do is re-create the lookup, because you cannot configure the list reference for a lookup field once it is created.
The downside of your import/export procedure is that you lose the validity of all currently existing lookup values. A lookup maintains its integrity based on the ID of the item it references. So when the display field changes, it still refers to the same item. If you delete the item, then the lookup no longer references it, even if you create a new item that has the same value for the display field. So you would have to reassign all of the products to the new product types.
It should be noted that if you were to revert the deletion of that item, it would return to being on the lookup! The reference to that ID is kept until the actual lookup value is updated (such as by editing the Product).
All of your now invalid references will be null for purposes of interaction. You won't see anything on display forms, and you won't have the options when you try to update the product. When you do update the product, you update it to what you just set it to, which since you can't set the non-existent IDs, means that there are no more references to those IDs.
Any changes to the Product Type list's schema that do not affect the display field specified for the lookup will not have any effect on the lookup integrity. If you do change the display field in any fashion, and of course if you delete it, then it will break in the same fashion as with the list reference. However, you can set the display field, both in the UI and in the object model, so it is easy to fix this.