I have a custom content type in SharePoint which has an approval workflow associated with it. The content type contains several Choice Site Columns. There is now a requirement to change the values of the choice columns AND update the existing content to reflect the new values.
Eg,
Existing Choices:
Choice 1
Choice 2
Choice 3
New Choices
Choice 1a
Choice 2a
Choice 3
So, some of the choices are being renamed.
As far as i can tell, whilst changing the choice column is straight forward, the existing list items won't automatically pick up the new values i.e. a list item with Choice 1 selected will still show Choice 1 until the list item is physically edited. But editing the item will require re-approval of the workflow. There are a few thousand items spread over several lists which will be affected by this change.
So, my question: Is it possible to suspend or detach the workflow whilst the changes are made and then re-attach / re-activate after the changes have been made, thus avoiding the need to re-approve everything? Or am i best to look at automating the re-approval?
Any help much appreciated
You could update the values using the object model, the SPListItem.SystemUpdate method that optionally allows you to prevent that a new version is created.
You could use SPSiteDataQuery to find all items using your content type and then update them using the method mentioned above.
Regards,
Daniel Karlsson
Related
Good Afternoon,
I am working on an existing SharePoint List with a web enabled infopath form with multiple views, containing questions that are asked at differnt stages of a workflow.
On the very first stage when the list item is created, there is a question with multiple choice (check one). For example, Field Name = Fruits, with values, such as: Apples, Oranges, Cherries.
Later on in the worflow, the user is sent a reminder email, similar to a survey, where questions may look like "What did you think of them apples?
New request from the customer:
In the customers world, every apple eater also eats oranges, and they want also know what the user thinks of oragnes.
So, it sounds like I need to create a conditional worklow that creates a copy of the list item when it is first created, to include all of the initial field values, when Apples is selected, but change the fruit value to oranges in the duplicate.
Note: The survey reminder is set to create an email reminder when a new item is create in the list.
Using a SharePoint Designer 2013 Workflow, how can I do this?
I noticed that SP Designer will not let me use the "Create item in list (Output to Varialbe:Create)" if the list is the same list. I assume this is by design to not create some sort of infinate loop. I guess MS does not trust that I have a carefully planted condition to only run once, which is what I need your help with.
It feels like a crazy idea, but I am considering making a copy of my list, and using Create item in list (Output to Varialbe:Create) to make a copy of the list item in list 2, to set all value the same, with the exception of fruits, where I would change the value to oranges, and then somehow create a workflow in list #2, to copy the list item back to list #1.
Thoughts?
Thanks!
I am trying to merge or copy data from either an excel spreadsheet or another sharepoint list into a master list. The main "item number" column will enforce unique values, but each item will be assigned to multiple "project numbers" using metadata.
Is it possible to tell sharepoint to auto-update the metadata when duplicate items are added to the list? I could probably even edit the metadata manually if it would display the old entry for modification, but the only option I've seen is modify or delete the new item.
Sounds to me(from the description you have given) you are trying to collate several lists in to one and any data within each list you need to merge. Is this correct?
If so you will probably need to do a bit of custom code. Heres a little run through.
Get the list objects of the lists containing your items or grab your items from excel.
Iterate through each of the items in the list(or excel) importing the items over to the Master list.
Just before the above step you will need to check if the unique identifier already exists in the master list. If it does grab that item and update it if it doesn't continue adding the item as normal.
As always i would recommend you have a crack at it yourself. It's far more rewarding to make something work yourself and to be honest to do the above if you can read other peoples code it should take too long to copy(i mean reuse :P) other peoples code off the web to get the desired outcome.
I am not aware of a way you would be able to do this out of the box or via SharePoint designer.
Hope this helps
Truez
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.
I am relatively new to SharePoint, working with WSS SharePoint 2.0. The "Issues" list template contains an "append-only" comment column. The great thing about this append-only comment column is that it saves a history of the comments entered every time you save, and it clears out the comment field for the next time you edit the item.
I would like to add this column to a custom list. However, when I add a new column, it does not give me an option to add this type of comment column - it only gives options for single or multiple lines of text. Is there a way to do this?
You can create an append-only column by choosing the Multiple Lines of Text option and selecting "Append Changes to Existing Text". I believe this only applies to lists, not document libraries. Other kinds of lists may restrict this, too.
if you're using SharePoint 2007, In the List/Library Settings click Add from existing site columns. Under Base Columns Append-Only Comments should be there. In order for the "tracking" to work Versioning must be enabled for that list/library.
Not having an append-only field in a document library made me pretty sad. But this template made me happy again:
http://www.microsoft.com/downloads/details.aspx?FamilyId=02C4D1B4-7D53-4B72-B577-3DA23F86EC17&displaylang=en
It's the Document Library and Review template and allows each document to have a "Discuss" button and related discussion thread.
In a SharePoint list I want an auto number column that as I add to the list gets incremented. How best can I go about this?
Sharepoint Lists automatically have an column with "ID" which auto increments. You simply need to select this column from the "modify view" screen to view it.
You can't add a new unique auto-generated ID to a SharePoint list, but there already is one there! If you edit the "All Items" view you will see a list of columns that do not have the display option checked.
There are quite a few of these columns that exist but that are never displayed, like "Created By" and "Created". These fields are used within SharePoint, but they are not displayed by default so as not to clutter up the display. You can't edit these fields, but you can display them to the user. if you check the "Display" box beside the ID field you will get a unique and auto-generated ID field displayed in your list.
Check out: Unique ID in SharePoint list
If you want to control the formatting of the unique identifier you can create your own <FieldType> in SharePoint. MSDN also has a visual How-To. This basically means that you're creating a custom column.
WSS defines the Counter field type (which is what the ID column above is using). I've never had the need to re-use this or extend it, but it should be possible.
A solution might exist without creating a custom <FieldType>. For example: if you wanted unique IDs like CUST1, CUST2, ... it might be possible to create a Calculated column and use the value of the ID column in you formula (="CUST" & [ID]). I haven't tried this, but this should work :)
I had this issue with a custom list and while it's not possible to use the auto-generated ID column to create a calculated column, it is possible to use a workflow to do the heavy lifting.
I created a new workflow variable of type Number and set it to be the value of the ID column in the current item. Then it's simply a matter of calculating the custom column value and setting it - in my case I just needed the numbering to begin at 100,000.
it's in there by default. It's the id field.
If you want something beyond the ID column that's there in all lists, you're probably going to have to resort to an Event Receiver on the list that "calculates" what the value of your unique identified should be or using a custom field type that has the required logic embedded in this. Unfortunately, both of these options will require writing and deploying custom code to the server and deploying assemblies to the GAC, which can be frowned upon in environments where you don't have complete control over the servers.
If you don't need the unique identifier to show up immediately, you could probably generate it via a workflow (either with SharePoint Designer or a custom WF workflow built in Visual Studio).
Unfortunately, calculated columns, which seem like an obvious solution, won't work for this purpose because the ID is not yet assigned when the calculation is attempted. If you go in after the fact and edit the item, the calculation may achieve what you want, but on initial creation of a new item it will not be calculated correctly.
As stated, all objects in sharepoint contain some sort of unique identifier (often an integer based counter for list items, and GUIDs for lists).
That said, there is also a feature available at http://www.codeplex.com/features called "Unique Column Policy", designed to add an other column with a unique value. A complete writeup is available at http://scothillier.spaces.live.com/blog/cns!8F5DEA8AEA9E6FBB!293.entry
So I am not sure I can really think of why you would actually need a "site collection unique" id, so maybe you can comment and let us know what is actually trying to be accomplished here...
Either way, all items have a UniqueID property that is a GUID if you really need it: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splistitem.uniqueid.aspx
Peetha has the best idea, I've done the same with a custom list in our SP site. Using a workflow to auto increment is the best way, and it is not that difficult. Check this website out: http://splittingshares.wordpress.com/2008/04/11/auto-increment-a-number-in-a-new-list-item/
I give much appreciation to the person who posted that solution, it is very cool!!