[Anonymous]

Quest Support is reporting that they are unable to reproduce this error.  Any of you that have an interest in this issue and you are running Sharepoint 2007, I would be interested in hearing if you can reproduce.

I am waiting to hear back from Quest Support regarding the steps they took.

Thanks!

Jim

[Anonymous]

This is indeed an issue with qListForm when Form type is set to NewListItem. qListForm performs a couple of actions after the new item is created (triggers create event). Some of the actions following the initial save will try to update dependent list item (trigger other dependent list items), or update Rich Text field (because user may add attachment to the field and list item ID will be needed after item is created) and etc. Quest will be looking into handling Rich Text update better in order to avoid this common issue.

[Anonymous]

We have fixed this problem in the current 5.4.1 release.

[Anonymous]

(Sharepoint 2007)

I am going to open a case on this, but I want to let the user community know about this.

Say you have a list and it has an On Change workflow.  If you put a qListForm on that list’s create page, subsequent use of that create page to create items will result in the On Change workflow being fired.

It should not be fired On Create.  But that is what is happening.

If anyone knows a reliable workaround, please let me know.  A colleague has suggested putting a check at the beginning of the On Change workflow and ending it if the Create and Modify time stamps match.  I will try that, but I am concerned about the time resolution and whether a false positive is possible (leading me to bail out when I shouldn’t).

[Anonymous]

Thanks for the update, !   That is good to hear.

[Author]

Posts