I hade the exact same problem last week and found no built in way of solving it. What I ended up doing was checking the value of beforeProperties and afterProperties of what I wanted to update, and if there was no difference, then I broke out of the method. I actually wrote a blog post about it.
This is an annoying problem that I hope Microsoft improves in ...
You probably have your event receiver registered twice. Use PowerShell to find out.
$site = Get-SPSite http://myportal.com
$web = $site.OpenWeb("/path/to/my/site")
$list = $web.Lists["The List"]
$list.EventReceivers | Select Type, Class | Order Type, Class
Disable event firing before you Update your item.
this.EventFiringEnabled = false;
this.EventFiringEnabled = true;
Note that this might cause problems when item.Update() throws an exception, leaving your eventfiring off.. you can use a try/catch to solve this.
hope I could help : )
RWEP is not available in the sandbox. Your alternative would be to grant a custom permission to the location where you are moving files to that grants the user Add Items or create a full trust proxy. For permissions, in your event receiver, you move the file normally. Users cannot modify items, users cannot delete items, only add new files. Fills the gap ...
Yes, it's possible to have multiple event receivers on the same list, but why you need to do that? you can add the new event function Itemupdating to the current event receiver solution!
In case you need to fetch the old value use Itemupdating with properties.ListItem
In case you need to fetch the new value use Itemupdating with ...
You must have wait for some time to check if the file is ready to use or not.
Means you need to wait till lock status SPFile.SPLockType.None becomes true.
Please check below code which applies System.Threading.Thread.Sleep(2000) for file to unlock.
if (SPContext.Current == null)
//If the initial file length is 0, pause the ...
You can make use of the SequenceNumber property that is associated with the SPEventReceiverDefinition object.
This property determines the order in which event assemblies execute. This is especially important when there are multiple assemblies that ...
What about checking out file before modifying properties? You check if file is available:
if true, you check out file, do changes and check it back in.
if file is already checked out you just wait (random amount of time) and then get file status again - after this you have available file or wait again.
There is no need to modify the file, but you can use ...
this.EventFiringEnabled = false; is used in Server object model. However, there doesn't seem to be its equivalent in Client object model. So the alternative is to check the field value first before making any changes to avoid the update operation recurrence. See similar question here: http://social.technet.microsoft.com/Forums/exchange/en-US/7f21121c-6bef-...
I believe the solution lies here.
You need to ensure the ItemUpdated event runs synchronously rather than async.
The ItemUpdated event by default will run after the page has already posted back and does not have a connection to the HttpContext of the firing page.
ItemUpdating should have a connection, but marking it as synchronous might help.
The solution is to use SPItemEventReceiver.EnableEventFiring MSDN
You can do
var eventRecTemp = new SPItemEventReceiver();
eventRecTemp.EnableEventFiring = false;
eventRecTemp.EnableEventFiring = true;
or as this blog talks about, turn it into a scope using IDisposable.
I used the scope method in an ItemUpdated heavy project and it worked well.
Just an alternate workaround if nothing else works.Since there is no built in method which mimics this.EventFiringEnabled the only way is to set a flag outside this item which will enable us to know whether the current update event is called by a genuine update through browser or external code or from an update called from an update event.
Create another ...
Some remarks that may help:
You may have an endless loop since the call to .Update triggers itself a new update and then the Event Receiver... You may not notice it immediately since SharePoint 2013 has now a protection that stops the re-entrance after 10 occurrences...
Simply add EventFiringEnabled = false; at the begin of your ItemUpdated method and then ...
Few changes here...Add the DisabledEvents class and allow unsafe updates. Also if you set the properties.ErrorMessage, it will show in the UI if there is an issue.
public override void ItemUpdated(SPItemEventProperties properties)
using (DisabledEventsScope scope = new DisabledEventsScope())
Yes it is possible.
If current user don't have permission to remove and add permission then you will need to enable "App Step" for workflow.It is same as "RunWithElevatedPriviledge" in SharePoint Server Side Code.
Please follow below link for enable App Step in Designer workflow.
After enable ...
Inside the MSDN link you attached, someone mentioned that on the After event receivers you cannot get the user who cause the event receiver to fire. That's incorrect, you can access the user info using properties.CurrentUserId or properties.Web.CurrentUser (The post you mentioned was marked and unmarked as correct answer...).
Also, you must ...
Try adding RoleAssigments to the new web, doing something like this (I edited a bit your code):
public override void ItemUpdated(SPItemEventProperties properties)
using (SPSite site = new SPSite(properties.SiteId))
using (SPWeb ...
In updateListItem() function:
Use var clientContext = new SP.ClientContext.get_current();
instead of var clientContext = new SP.ClientContext(siteUrl);.
Also, make sure that you are passing display name(Not the name in URL) of list in following line:
var oList = clientContext.get_web().get_lists().getByTitle("RiskMgmt");
No need to create a specific solution for every document library,
Just create one SharePoint solution with an event receiver for a Document Library as shown below:
Note: In Elements.xml don't change ListTemplateId="101" theat denote to document library
In each event, you have selected. you can check if the doc title equal a specific doc library title, ...
You've stated that you're doing a web.EventFiringEnabled = false in the event receiver for List1.
This will disable event firing across your entire web, including for List2. This explains why your event receiver for List2 is not firing.
I don't think so. ItemUpdated is asynchronous, so by the time it fires, a response has already been sent back to the browser. If you do not have access to the HTTP Request and Response, you can't tell the browser to redirect.
In the ItemUpdating ER the value properties.AfterProperties["vti_contenttag"] is null when the doc is added, overwritting another one.
This could be a way to go, not the best for sure, but still a working solution
There are two ways I can think of.
Create a timer job. Schedule a SharePoint TimerJob to run daily or for every n number of hours and populate a list which will contain the excel file content.
Design a Business Connectivity Service through Visual Studio and let it read data from the excel file every time it is loaded. This does not have any issue from the ...
Instead of an event receiver, can you utilize the Content Organizer feature instead? http://msdn.microsoft.com/en-us/library/office/ee558288%28v=office.14%29.aspx
Your users can be given write access to the drop off library. They do not need access to the final destination library -- the content organizer process will move the on their behalf.
I have not personally run into this issue but it sounds a lot like an unsafe update error. Assuming properties.ListItem is a reference to the newly moved file and not null or somehow have a reference to the old file location, you can try something like this:
movedFile.Web.AllowUnsafeUpdates = true;
movedFile.Web.AllowUnsafeUpdates = ...
Can't you use the "Link to Document" content type ? This means you could have one copy of the SOP and then have a series of Links to it in your other libraries. I also blogged about this : http://www.collaboris.com/blogs/collaboris-blog/policy-management/2013/04/03/use-a-link-to-a-document-in-place-of-an-real-document-in-sharepoint#.UtH_3PTrwdU
Try checking the item.AfterProperties or the item.AfterUrl. It's weird that you can't get the item by using its UniqueId, but you have to check other things as well.
Is item in your case properties.ListItem, where properties is of type SPItemEventProperties? If not, that could also be the culprit as you should work with the item passed into your event ...