ItemUpdating

May 4, 2012 at 11:34 AM

To all,

I have written an ItemUpdating EventReceiver updating a list when a Boolean field changes from true to false. When changing the field using the UI (Edit Item) all goes well and the intended list is updated and the some workflows are started.

When using SPServices to update the very same field nothing happens. as far as I can tell the ItemUpdating Eventreceiver does nor even fire.

Hope somebody can tell me what I am doing wrong here.

Thanks in advance,

Luc Denys

Coordinator
May 5, 2012 at 6:00 PM

Luc:

As you might expect, I'm not an event receiver writer. I honestly don't know if an update via the Web Services has the same "oomph" that any other update would have, but it would really surprise me if it didn't. I believe that workflows fire on item updates via the Web Services. Perhaps your event receiver is trapping on the wrong event?

M.

May 7, 2012 at 3:49 PM

I'm not sure about the workflows but I do know if a user is subscribed to alerts, the alerts are triggered when I use SPServices to add new list items to the subscribed list.

May 7, 2012 at 5:36 PM

I'm with Marc, I'm pretty sure they do fire workflows like you would expect. However you can always call the web service to run the workflow in your jQuery code. :)

 

Cheers,
Matt 

May 7, 2012 at 9:45 PM
I can confirm that Workflows are triggered by updates done via Webservices from the browser... I currently maintain a solution where workflows are triggered on item create as well as item change; in both Lists and Libraries.

_________
Paul T

May 8, 2012 at 10:24 AM

I think that this should work for you. Something to test would be to see if there is a difference in the properties. Unfortunately this is done in the EventReceiver. You could use something like this:

if (!properties.AfterProperties["AssignedTo"].ToString().Equals(properties.ListItem["AssignedTo"].ToString()))

So you can change AssignedTo to match the field you are checking to be sure that they are the same or different. In this case I was testing to see if the user who filled out the form had changed who the task was assigned to. Notice the ! (NOT) operator.

( Sorry for the c# contamination folks! :-)  )

May 8, 2012 at 1:28 PM

Thanks to all those that took the time to respond. Finally found the mistake I made.

First I used the following code

          $().SPServices({
            operation: "UpdateListItems",
            listName: "Cursussen",
            ID: courseID,
            valuepairs: [["AfwezighedenOk","1"]],
            async: false,
            completefunc: function(xData,Status){}
          });


The Field AfwezighedenOk showed as checked in the UI, so I thougt there was nothing wrong with this code. But I was wrong. Changing the code to

          $().SPServices({
            operation: "UpdateListItems",
            listName: "Cursussen",
            ID: courseID,
            valuepairs: [["AfwezighedenOk","True"]],
            async: false,
            completefunc: function(xData,Status){}
          });
did the trick.

Finally found the mistake analyzing the log file ( String was not recognized as a valid Boolean.). 

Once more, thanks to all.

Coordinator
May 8, 2012 at 1:50 PM

Great! So the lesson here is that an update with the Web Services is on a par with one through the UI, I believe. That's what I would have expected, but I'd never needed to test the assumption.

M.

May 8, 2012 at 3:15 PM

Yes, but it may sound strange, but I thought that SharePoint was weird with its boolean values. I have used a numerical value, but for some reason I thought in SharePoint that "Yes", "No" was valid as is "True", "False", and I at one point used "0", "-1" but can not remember which of these were true or false. Just adding this as something that I have seen before. "1" was never valid, but "-1" worked. Strange right!

Coordinator
May 8, 2012 at 3:20 PM

I've seen that you need to use different values depending on how you're coming at it, whether it be the object model, the Web Services, the UI, etc.

M.

May 8, 2012 at 4:29 PM

That's goofy...  I wonder if sorting through the XML from a GetList operation could shed some light on this.

May 9, 2012 at 12:56 PM

I use the UpdateListItems method to update boolean values in lists in a few places.  I simply use true or false as the value in the valuepairs argument (without quotes around them).  Ex:  valuepairs: [["SelectedForAward", true]],
I never have any trouble with that syntax.

May 9, 2012 at 1:42 PM

I've never ran into this at all.  I've always used 1 and 0 for my bool values.  Wonder if there's something under the hood that could be causing this stuff.

May 9, 2012 at 2:12 PM

The updating goes alright indeed. It is the event receiver attached to that list that is throwing an exception saying that 1 is not a valid boolean string. Maybe the updating process does some magic with the procured value. Magic that is not yet done when the eventreceiver kicks in.

May 9, 2012 at 8:37 PM

I believe that you need a -1 for that in the event receiver.

From: lucdenys [email removed]
Sent: Wednesday, May 09, 2012 10:12 AM
To: evilgenius@cox.net
Subject: Re: ItemUpdating [SPServices:354526]

From: lucdenys

The updating goes alright indeed. It is the event receiver attached to that list that is throwing an exception saying that 1 is not a valid boolean string. Maybe the updating process does some magic with the procured value. Magic that is not yet done when the eventreceiver kicks in.