Tag Info

New answers tagged

2

It is really depend upon you requirement. from simplest way to workflow to event receiver. Simple way is using the calculted column use the workflow( personally i dont like this) event Reciever: By using this strategy, users have advantage to edit the existing values, we can also avoid it by making field read-only on feature activation. Using item event ...


2

Using an event receiver: You can check the last added item, then increment it with 1. Then modify the number as 2014/001, 2014/002 and ect... No need to have workflows. Another way is having a property bag value which stores the last added id, then increment it by 1 and save, set that value to the number to the list item. This too can be done using an ...


1

Yes they run under the w3wp worker process, you have to attach to OWSTIMER.EXE for debugging. Check this blog, he talked about the how to debug the event received. Debugging Event Receivers in SharePoint 2010 Key steps: now my process works like this: Compile Deploy net stop sptimerv4 net start sptimerv4 Run my code and hit my breakpoint I'm actually ...


1

Talked to MS support regarding this and He told me that this is the expected behavior for app uninstall. His argument was that app is like any other object within SharePoint and once you delete it, it should go to recycle bin for any recovery possibility. It stays there for 90 days. I also discussed about change of behavior for Uninstalling event receiver. ...


2

no that code above is only required within the updating event. Say i have an added event and updating/updated event. when the added/adding event is triggered it will then trigger the updated/updating event. you can put the code within the item adding or added so that it doesnt trigger the updating event at the same time. the point of the code is to stop ...


4

public override void ItemUpdating(SPItemEventProperties properties) { try { //is the item checked out? if (isCheckin(properties) == false) { this.EventFiringEnabled = false; //do your stuff } } catch(Exception a) { //catch any errors } finally { this.EventFiringEnabled = true; } } private bool ...


3

For the scenario when you are the one triggering the second ItemUpdating by changing item values you can use the EventFiringEnabled parameter (you should use a try - catch -finally around it): this.EventFiringEnabled = false; // Do the changes item.Update(); this.EventFiringEnabled = true; The other scenario is tougher, and the reason behind why I use ...


1

You can put a check like this : SPFile file=item.File; if(file.Level==SPFileLevel.Published) { if (file.CheckOutType == SPFile.SPCheckOutType.None) { file.CheckOut(); // Checking out the file } }


1

Yes you can check what is the status of the document in the library. Check this code: SPListItem listItem = GetListItem(); var moderationInformation = listItem.ModerationInformation; if (moderationInformation != null) { if (moderationInformation.Status == SPModerationStatusType.Approved) { //approved } else if ...


0

I stumbled across this issue as well. Though your solution works, there is an easier way of solving it. In ItemUpdating the value of a Managed Metadata field in the AfterProperties is a string. So instead of doing what you have done, you can just create a new instance of the TaxonomyFieldValue. TaxonomyFieldValue newValue = new ...


0

This type of functionality doesn't exist in SharePoint (yet!). However you can create it yourself by a combination of social feature development combined with remote event receivers. Get started developing with social features in SharePoint 2013 How to: Create a remote event receiver Adventures with SharePoint 2013 Remote Event Receivers – Part 1 of 3


2

I think that you should not to use properties.Dispose() method, furthermore you should not to use properties.Web.Dispose(). I'm sure these objects are used in SharePoint later. As workaround you can try to use this snippet: using (SPWeb web = properties.OpenWeb()) { //code }


1

Generally scope should be Web because Event Receivers are triggered by certain events on either a SPWeb, SPList or SPListItem. We can categorize SharePoint events in two different categories: by the “level” which fires the event (site, list, item), and by the type of the event (synchronous and asynchronous). Again depends what you want to achieve... scope ...


-1

Event Receiver Feature must be set as Web Scope.. http://msdn.microsoft.com/en-us/library/ms454835.aspx


0

I would first check if your Event Receiver is attached to the list. It's easy to view all attached Event Receivers with PowerShell: $web = Get-SPWeb <Url> $list = $web.Lists["<ListName>"] $list.EventReceivers



Top 50 recent answers are included