[Anonymous]

– I am interested in the custom code – thank you!

Jim

[Anonymous]

Hi Jim,

   Since you're on version 5.2 I can't speak to much about it since I was not with the team at that point.

What I can tell you is that since the version 5.3 release I dealt with one case somehow related with your issue.

That was about a SharePoint migration (2007 to 2010) that involved a lots of SP out of the box workflow and Nintex workflow migration and the customer experienced an issue with Nintex worflows.

To troubleshoot that I provided him some custom code that triggered a workflow with debug information. It looked that he figured out the solution since he hasn't got back to me.

The issue that you mention from 5.4.1 release notes has been fixed.

PS

I can provide the same custom code to you if you think that could help (hope that it works with QWP 5.2).

[Anonymous]

Hi Jim,

Please send me an email at nicolae.anca@quest.comand I send you the sample code by email.

Please note that this sample code is for investigation purposes only and is provided with no warranties.

The code is a custom action code that starts a workflow and logs some info about it. Check the file pleCustomActionEx.cs

One thing I forgot to mention in my previous note and that is that I've seen weird things happening on lists that have multiple workflows running concurrently.

[Anonymous]

I sent the attachment by email but it was rejected by your company's policy.

Please let me know if there is any other way to send you the files.

[Anonymous]

Thanks for your patience on this, – I am glad we found a way to get the files sent. Unfortunately, our standard is Visual Studio 2008; it is not allowing me to open your project, saying it was built with a later version.

One additional point to make regarding the original question:

The event firing concerns actually did not originate in the context of Nintex or WWF at all, but in terms of custom .NET event handler code. We have very isolated cases where the event handler code never gets fired at all. It is a big problem, because the event handler code is what applies the item level permissions to the items, and so with the code not firing, sensitive HR data is left exposed.

But we have also see cases where Nintex workflows did not fire either, that should fire on change.

The common thread in these cases is Quest. We know that there were some corrections made to event firing scheme in some versions of QWP sometime between 5.2 and 5.5 – specifically 5.4.1 I believe. Given that such changes are being made, we suspected that perhaps the earlier versions had some bugs that had to be addressed. We are hoping that in addition to the other bugs that were corrected, there may have been some DisableEventFiring bugs that were also fixed, but since the problems are so sporadic, proving that with our sandbox 5.5 installation is a crap shoot.

Upon reading this, you will no doubt be interested in me elaborating on the event firing fixes in 5.4.1, but I would need to defer to my co-workers for that. I will send them a link to this thread in case they want to chime in (hopefully so).

Thanks!

– Jim

[Anonymous]

Issue US143516 was part of the 5.4.1 release. The description was “When qListForm is in NewListItem mode, it seems to trigger the item changed event when associated with workflow” (I love that wording “seems to” LOL).

Question – have any recent releases done anything to address sporadic cases where Quest disables event firing? We have used qListForm extensively, and on three such sites we have had sporadic (unreproducible) cases where the On Create and On Change events apparently never fired at all. The result is that our associated backend logic never gets initiated, resulting in serious business data issues including security exposure and issues with financial calculations.

Our backend logic includes some sites where we are employing out-of-the-box workflow functionality and other sites where we have custom event receivers that we have built ourselves.

In both scenarios, the logic does not execute. Of course, of the two scenarios, the workflow case is the only one we can “prove”, since we can use the interface Sharepoint provides to show workflow history (or lack thereof).

I have reviewed the revision history of 5.4.1 and 5.5 and I do not see any mention of any such fixes.

Thanks!

Jim Boling

International Paper

Quest Web Parts v5.2

Server OS: Windows 2003 R2 SP2

Standard Browser: IE8

[Anonymous]

Hi Jim,

  You can use the project bdoing the following.

Createa  new project in VS2008 and add the *.cs files to you project.

This would work for you since the VS project version is not important in our case but the content of those cs files.

If you wnat ot see what has been fixed and what are the known issues in 5.5.1 (or any other later version) please read the release notes of the particular release you're interested in.

Please let me know if you still have question/concerns.

Thanks,

[Author]

Posts