I'm trying to implement a remote event receiver for SharePoint Online.
This RER should be used to intercept the override action of a document in a document library and avoid that possible metadata already in the document that i'm uploadnig are updated in the document library.
Right now the RER is the only way i've found that can help me in this situation.
The idea was to listen to the event "ItemUpdated" and replace the new properties with the old ones if they are changed.
The problem is that there is no specific event for an override of a file. The only event that is triggered is the "ItemUpdated", that is triggered both when a file is overridden but also when manually someone change the metadata in the file directly in SharePoint.
I've found no way to understand if the ItemUpdated event has been triggered from the override or just a manual update.
I need to block the change of the properties ONLY if I'm overriding the file.
Any possible help or idea?
Thanks
I need to understand if the event is triggered from a file overriding or just a metadata change.
Related
Experienced .NET developer here (but only client object experience in SharePoint). Here's my scenario:
In SharePoint 2013 a user checks in an existing/new file after making changes
File check code (c# pref) is run against the file being checked in
If file passes checks continue check in
If file fails, discard check in, inform the user that the check in has failed & provide the reasons why it failed (reasons supplied by file check code).
I already have the file checks implemented as a c# class lib (used in a couple of other apps). I would like to be able to limit this to a specific folder (and all child folders within) and file type (identified by file extension).
What's the best practices method of implementing this? My guess is to tie into existing SP events to determine check in and insert my file check class into that execution path. In a perfect world I'd find a tutorial demonstrating this. :)
Thank you in advance for your time.
Regards,
Falconeer
what you want is to develop a SharePoint farm solution which uses the event receivers. There are specific event receivers which will fire when someone checks in a document. Then you should do your logic there.
http://beginnersbook.com/2013/02/event-receivers-in-sharepoint/
Watch out for the event receivers - checkingin - checkedin. There is a difference between the two. The one is synchronous, the other asynchronous. I would put your logic in the -ing event receiver as this allows you to cancel the checkin.
You might have to play with before and afterproperties to do the appropriate check on folder, file, etc...
http://www.sharepointalex.co.uk/index.php/2010/06/beforepropertiesafterproperties-in-event-receivers-i-always-forget-this/
This should be the way to go!
How I may know which file is modified and what data is changed in the file?
Edit: I want to watch the file as it gets modified and then compare it against a previous version to know which data blocks are changed. I guess watching the file for changes can be accomplished by using file watcher API but I have no idea about the second part.
You may need the FileSystemWatcher class.
The most common approach is define FileSystemWatcher, subscribe to its events and process them accordingly to the logic of your application.
Here is a simple example.
I have a program that reads an XML file (for now, on local computer.) and loads the data into a list of struct.
How can I make it such that if I execute it, it does the above but then waits to keep checking for any change to the file. Should the file be changed, it reads the file all over again.
Do I need to create a file watcher service as described here:
http://www.codeproject.com/KB/files/C__FileWatcher.aspx
You need FileSystemWatcher - the docs give examples.
Basically you create an instance, give it a filter (which would be your exact file in this case), hook up an event handler (probably the Changed event in your case) and then set EnableRaisingEvents to true.
You'll want to look at the System.IO.FileSystemWatcher class. You can have it raise an event in your code when the file is changed.
Details can be found on MSDN: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
Look at the FileSystemWatcher class. You can point it at your XML file and when it changes, it will fire an event so you can then read the file again
I want to get an event Before a file is being deleted?
How can I do it?
As per my answer to this question: How could I prevent a folder from being created using a windows service?
There's no support within the System.IO.FileSystemWatcher, or anything else within the .net Framework (as far as I'm aware) for receiving an event prior to a file being deleted, i.e. at the point the deletion request hits the file system, but prior to it being actioned (I'm assuming here that you want to be able to selectively cancel requests to delete files).
What you'll need to do, if you want to go down this route, is write a File System Filter Driver, which you'll have to write in unmanaged code as far as I'm aware.
I have an application that has created a number of custom event log sources to help filter its output. How can I delete the custom sources from the machine WITHOUT writing any code as running a quick program using System.Diagnostics.EventLog.Delete is not possible.
I've tried using RegEdit to remove the custom sources from [HKEY_LOCAL_MACHINE\SYSTEM\ControlSetXXX\Services\Eventlog] however the application acts as if the logs still exist behind the scenes.
What else am I missing?
I also think you're in the right place... it's stored in the registry, under the name of the event log. I have a custom event log, under which are multiple event sources.
HKLM\System\CurrentControlSet\Services\Eventlog\LOGNAME\LOGSOURCE1
HKLM\System\CurrentControlSet\Services\Eventlog\LOGNAME\LOGSOURCE2
Those sources have an EventMessageFile key, which is REG_EXPAND_SZ and points to:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
I think if you delete the Key that is the log source, LOGSOURCE1 in my example, that should be all that's needed.
For what it's worth, I tried it through .NET and that's what it did. However, it does look like each custom event log also has a source of the same name. If you have a custom log, that could affect your ability to clear it. You'd have to delete the log outright, perhaps. Further, if your app has an installer, I can see that the application name also may be registered as a source in the application event log. One more place to clear.
What about using Powershell?
Remove-EventLog -LogName "Custom log name"
Remove-EventLog -Source "Custom source name"
I was able only to delete it by using:
[System.Diagnostics.EventLog]::Delete("WrongNamedEventLog");
in powershell
Perhaps your application is fault-tolerant, meaning that it checks to see if the event log source is already registered and registers the source if it isn't?
If this were the case, your application would re-create the source(s) each time it ran, no matter what you did.