I need to copy the item that user just added (for example. myresume.doc or financial.xls) with the metadata (doc lib obtains the columns from content type, ct obtains the columns from site colum) and copy the item with metadata in a folder called "NativeFile". Every doc library has this folder.
I know itemadded can be used but then I heard itemadded fires before user have a chance to complete the metadata for the item they just added.
What are my options? (new to sp, so some sample code would greatly help. or some good link similar to this issue)
Sharepoint 2007, itemadded or itemadding or itemupdating or itemupdated....
ccomet is correct. With item event receivers alone there's no good way to duplicate the metadata. If you can get away with just copying the file here's whatcha do:
public class MyItemEventReceiver : SPItemEventReceiver
{
public override void ItemAdded(SPItemEventProperties properties)
{
base.ItemAdded(properties);
SPListItem item = properties.ListItem;
item.File.CopyTo(item.ParentList.RootFolder.Name + "/NativeFile/" + item.File.Name, true);
}
}
What you've heard is correct: ItemAdded will fire before metadata completion because in a document library, ItemAdded fires when the document is first uploaded and not when the form is filled out.
I think the smoothest option is to use a workflow that fires off when an item is created in the document library. Specifically a code-based one using Visual Studio 2008, if you have it. A general walkthrough of making workflows using Visual Studio 2008 can be found here: Wrangling SharePoint Workflows with Visual Studio. That article is actually how I learned to make workflows from in the first place, so I hope it helps you as well as it has me. I would recommend this approach over an event handler because you would have to use ItemUpdated, which means you'd have to do tricky checks just to ensure this only runs once. And the other option I can think of, which is making a custom form, is not very comfortable to have to do all of the time.
Now, make your own workflow. Make sure to initialize the workflowProperties like shown in the link for the onWorkflowActivated_Invoked. This is a very simple workflow if you make all of the necessary fields Required in the form. In designer view, all you need are 2 additional activities besides the OnWorkflowActivated activity: an OnWorkflowItemChanged activity, and a Code activity. For the OnWorkflowItemChanged activity, the only property you need to set is the CorrelationToken, which will be the same as the OnWorkflowActivated activity's CorrelationToken. Now, double click the Code activity to generate its codeActivity_Executed method. In this method, the following should suffice:
SPListItem item = workflowProperties.Item;
if (!item.File.Url.Contains("/NativeUrl/"))
{
string destination = item.ParentList.RootFolder.Name + "/NativeFile/" + item.File.Name;
item.File.CopyTo(destination, true);
}
I added the if statement because the workflow will probably trigger on the new item you created by using CopyTo, so this will check to see if the file is already in the folder, and if it is, it won't do a copy. Now, associate the workflow with your website like demonstrated in the link, and associate it with item creation. It should work, then.
Even though this workflow techinically waits for ItemUpdated, because that is when the fields are filled out, by associating it with creating an item, you ensure that it only runs once. I do admit that I've only used item.File.MoveTo(destination, true), but that does retain all of the fields and metadata, so I'm pretty sure the CopyTo should as well. If not, just give a holler.
Just copying the Properties collection from a source item to a destination item doesn't work for all file types, especially when they are located in different document libraries.
See this thread for more details: https://sharepoint.stackexchange.com/questions/1151/what-is-the-best-way-to-copy-a-files-column-data-in-sharepoint
Related
I have a list (assume an issues list) and there is a workflow associated with it. The workflow can adjust the status column of the item to "Closed". Once an item's status is closed, I want to make it read-only so that noone can edit the item or create another workflow instance for that item.
What's the best way to achieve this?
There are item-level permissions that can be set, so you can override list-level permissions on an item-by-item basis. Adding this functionality into your existing workflow probably makes the most sense, but of course there is nothing out-of-the-box that SharePoint provides you.
Luckily, you can extend SharePoint's workflow by creating your own custom actions. The process for doing this in SP2010 is fundamentally the same as 2007; check out this MSDN tutorial for an overview of the process.
There is also a convenient package of custom activities provided in an open-source product called SPDActivities at CodePlex. Specifically of interest to you is the Grant Permission on Item activity. Even if you opt not to use the whole package, you can examine the source code and see about implementing your own version of it (I did something similar for a past project).
Once you have a workflow action for setting an item's permission level, simply add a step to your existing workflow to set Read permission for the affected audience or group.
Have you looked at SPUtility.js? You could get the value of your status field, and then if it is Closed, make the other fields read only (or hide them). This is done using JavaScript that is added in a content editor web part on your EditForm.aspx.
var myChoiceField = SPUtility.GetSPField('Single Choice Field');
if (myChoiceField.GetValue() == 'Closed') {
SPUtility.GetSPField('Field A').MakeReadOnly();
SPUtility.GetSPField('Field B').MakeReadOnly();
SPUtility.GetSPField('Field C').MakeReadOnly();
// etc..
}
Full disclosure.. this is an open source library I maintain. I've tested it with SharePoint 2007 only, but it may also work with SharePoint 2010 (unfortunately I don't have access to a SharePoint 2010 environment to test).
I would attack it one of two ways:
Once the workflow completes and sets the item to Closed, you can break the permissions inheritance from the parent list and set the list item permissions to read only. You could do this within a custom workflow or as either a Workflow or List Item event receiver.
Have an ItemUpdating List Item event receiver that sets properties.Status = SPEventReceiverStatus.CancelWithError if status is Closed.
Personally, I like the first option better as it fits in with SharePoint's security philosophy of not letting the user attempt what they do not have permissions to do. The following code is an example of setting read only permissions on a list item:
item.BreakRoleInheritance(false);
SPRoleDefinition role = web.RoleDefinitions.GetByType(SPRoleType.Reader);
SPRoleAssignment assignment = new SPRoleAssignment(web.AssociatedVisitorGroup);
assignment.RoleDefinitionBindings.Add(role);
item.RoleAssignments.Add(assignment);
Try creating an Event Receiver and handle the deleting event.
Idea (un-tested): Add a custom content type to the list (this will allow you control to edit as an admin later). Have workflow switch to the custom CT one the item is "closed". Add a read-only view of the item data to your EditForm.aspx, and in Designer add class "hidden" to your read-only view. Then add custom css in a CDWP on the page for class .hidden display:none. Then use JavaScript to add/remove that class based on the CT, so that the read-only view is only visible for the custom CT, while the edit wp is visible for all others.
Or use a custom InfoPath form to switch to read-only view based on status...
I'm just starting to use sharepoint designer and realised there's a lot that can be done to extend the basic features in sharepoint. We have an email alert sent out when a new task is created (by the user) and I want to customise the email so that it also includes a link called 'Assign'. When clicked, I want this link to automatically update the task with the assigned to field for the person that clicked it.
So I think the way to do this would be to hard-code the assign to value in the url behind this link, but I have no idea if this is possible or if there is an easier/better way to do this.
Any advice would be appreciated as I'm a complete beginner.
thanks.
I will not cover "How to modify the contents of an eamil alert" here as that is a seperate question and there are a lot of articles that cover that already.
For the Assigned link :-
You would need to create a custom page (or web part on an existing page) as the destination of your Assign link - this would take the Task ID as a query string param and then update the assigned to with the current user.
You could make this flexible by also taking the ListID but you may want to think about how this could be abused and put appropriate measures in place.
EDIT - in response to comment.
This is top of my head, not checked in compiler. This would have to sit on the same server as SharePoint to work as its using the OM - if you want to use a different server (why would you though) then look in the web services.
private void updateAssignedTo(Guid listId, int itemID)
{
SPWeb web = SPContent.Current.Web();
SPList list = web.Lists[listId];
SPListItem item = list.GetItemById(itemID);
item["Assigned To"] = web.CurrentUser;
item.Update();
}
You're going to have to work out how to get this code into to page or web part (SharePoint Designer is not going to cut it I think, you need Visual Studio) but its a starting point.
I'm working on a SharePoint publishing site and I want to "log" all the changes made by users in a SharePoint list.
Some searches on the web guided me to the EventReceiver.
But my EventReceiver must be generic and attached to all lists in the site collection. The "log list" has several columns like the name of the list in which the event occurred, the name of the modified item, its old value and its new value.
Can someone guides me on how to achieve this?
There's already a provided answer for you on StackOverflow, hurrayy!!
It sounds possible. Create a class that inherits from SPItemEventReceiver and override ItemUpdating. You can use the following code to get the list:
using (SPWeb web = properties.OpenWeb())
{
SPList list = web.Lists[properties.ListId];
}
You can then use list to grab the list's title and URL. Next, compare each DictionaryEntry entry in properties.AfterProperties to the corresponding value in properties.ListItem to get your differences. Then save it to your log list. The trick would be automatically attaching your Event Receiver to each newly created list. Perhaps a timer job would work.
That said...
Before trying any of that, go to your site collection's Site Settings. Under Site Collection Administration, click Site collection audit settings. Under Specify the Document and Item events to audit, check Editing items. Only go with a custom solution if that does not give you what you need.
Would Version history not achieve the same functionality?
You can see what fields were changed by who and when. Though you would have to look at a list by list basis.
You can also access the version history information via the object model if you want to generate reports web part.
Otherwise using Janis Veinbergs link on how to attach a event handler to all lists and Rich Bennema method of getting the values from the updated item in a generic way, though I would use ItemUpdated as you don’t want to change the data that was updated only copy it to another location so there is no need to catch the data before it is submitted to the SharePoint database
I'm aware of the event receivers on a list for items added etc. However, I have not found a way to fire code upon the creation of a list.
What I'm trying to do is associate a workflow with a list when the list is created (by the user through the UI).
Anyone any ideas?
thanks.
There are a couple of routes you can take...
You can write your own list definition where you have defined the workflow association - That way all lists created based on your list definition, will contain your workflow on default.
Or... depending on your workflow... write an EventReceiver your attach to all lists of the type you wish to attach your workflow to (can easily be achieved tru a feature) and have your event receiver associate the workflow when the first item is added.
or you can associate the workflow to the contenttype used in the list (your own contenttype you attach to your own list definition or a default SharePoint contenttype)
I don't know the rest of your solution, so it's defficult for me to suggest the best solution for you.
What I (almost) always do, is write my own list definition - That way I can avoid problems like this, now or in the future.
With SharePoint 2010 it is now possible to hook into the list creation event by overriding the ListAdded event in the SPListEventReceiver class.
I usually deploy an extra view page which is set to the default view. When the user creates the list he will be sent to the viewpage which contains the setup in code behind. The view page then calls a method ive created, which changes the default view, removes the setup view and change any navigation node pointing to the setup view.
There is probably no perfect answer to this question because there is no list added event receiver (if memory serves me correct).
I don't know if this is the case, but if you really just needed to register an itemadded (or updated, deleted, etc.) event to any new list, I believe you can register the those events at the site (SPWeb) level and they will fire on any new lists created.
Which is the best way to display a custom form for each new document being added to a specific document library?
I want the user to have some control over some actions that adding the document will cause - specifically, tasks created for users in a Task List, which the contributing user will have to OK before committing.
Is the best way to do this via a Workflow or an event handler?
Regards
Moo
For SharePoint server 2007:
A combination of a specialised content type and an event handler will give you the most control of the process (easier to debug too). A workflow is best for "easy" actions and is harder to make complex actions happen.
A workflow allows for more flexibility in assigning the workflow to different libraries by site admins.
Roll your content type and event handler into a feature that can be deployed. Assigning the content type to a list will allow you to take any data created by the standard form (remember you can create custom fields for really complex/custom data entry) and take any action required, including creating tasks based on the item.
Thanks for the answer, thats the route I was investigating but unfortunately I haven't found a way to make it work for Document Libraries - only Lists.
The problem I have come across is that aving a SPUtility.Redirect in the ItemAdded, ItemAdding, ItemCheckingIn or ItemCheckedIn event on the document library doesn't do anything at all, because there is no page related to the events - its all backend code being fired that is not linked to a web context, because its not the webpage doing the heavy lifting at that point but the Office integration.
All of the examples I have come across seem to rely on the fact that the EditForm.aspx or NewForm.aspx page is being displayed at the time the event is fired, which of course is not the case here.
This also leads to the problem that I cannot extend the EditForm.aspx or the CheckIn.aspx page to do what I want either, because Office 2007 circumvents both of these.
So, the only option left open to me at the moment is doing it through a workflow :/
Any further tips would be fantastic.
I may not understand your question, but is this close to what you're trying to do?
http://msdn.microsoft.com/en-us/library/ms550037.aspx
If not, in what way does this come up short?
A new "Content Type" with its New Form url set to the appropriate value should do the trick.
Unfortunately you may not be able to achieve what you are trying to with an Event Handler or a Workflow. You would ideally want the form to show up as soon as the user adds a new item to the library and a custom content type will do the trick.
Create a new Content Type. (Derive it from the existing Content Type)
Remove the default content type from the doc library.
Using the Object Model to set the New Form url to an aspx page or an Infopath form you've created.
Kind regards,