- This topic is empty.
- 09/01/2011 at 2:19 am #4979
I am seeing a similar problem, it only happens with some users that are using Windows 7 and IE8. Other users don't seem to trigger the behavior. I have not had any luck tracking down the cause.
- 09/02/2011 at 1:23 am #6432
Hi Robert, Paul,
The double entry happens when the users make a quick double click on the save button or just one click?
If that happens because of a double click then I'd recommend you to create a custom action, then add two action, first one of Save type then the second of type GoToURL that would redirect the user to a page that you can define.
- 09/02/2011 at 3:18 am #6433
I tried making this modification but the duplicates are still happening. I'll try running some more tests to try and narrow down the source of the problem.
- 09/07/2011 at 9:21 am #6434
Boy, I hate to hear that this is still happening. The problem with the custom action workaround is that you lose the newer functionality of the standard submit, which was supposed to address some of this problem in the first place. It would be nice to have a property on custom actions that will lock the screen similar to what the standard submit button now does. But then, if it isn't doing what it is supposed to do…
- 09/07/2011 at 9:28 am #6435
I really appreciate your help in solvig the issue.
We tried to repro the issue in our test env. but we just couldn't.We'd be happy to fix the issue but since it doesn't happen we don't know what causes the duplication.
Do you have any virtual env. that I could borrow from you and see if we can find something useful?
Any other idea? What's so special a out thse environments?
- 09/07/2011 at 10:12 am #4029
I have used the qListForm web part on the default NewForm.aspx page (and hiding the OOB Sharepoint list form) in a custom list. Recently I’ve noticed that duplicate items are often created when adding a new item to the list. The behaviour is not consistent – sometimes only one item will be created and sometimes two. Without having done much digging for the problem I get the feeling that this problem has arisen after we deployed Quest Web Parts 5.4 in early January.
Has anybody else seen the same behaviour?
- 09/07/2011 at 10:12 am #6436
I am not surprised you were having problems reproducing the issue. I am currently working with two co-workers that are able to reproduce the issue, but I am not able to reproduce it either, even though we are using the same OS (win7) and web browser (IE 8). Compatibility mode does not seem to change anything. Unfortunately I don't have any way of providing access to our environment. Are there any other details I could gather from the machines that might assist in identifying the problem.
- 09/20/2011 at 9:23 am #6485
I don't think I can mark this as answered as I did not start this thread.
- 09/20/2011 at 10:03 am #4958
After further research we have found this problem is being triggered by a IE password manager plugin called LastPass, when this plugin is disabled the behavior goes away.
- 09/20/2011 at 10:07 am #6685
This is great info, I really appreciate your update.
Would you mind to mark this post as answered/helpfull so other people know a possible workaround.
- 10/03/2011 at 8:18 am #6686
Sorry I've been out of the discussion for a while, I've been on parental leave. We are not using LastPass on the corporate level and the behaviour has occurred with too many users for there to be any probability that they would be using it individually. I'm not seeing the issue now and I've always had a problem reproducing it (although I have been able to on occassion). Not expecting a solution at this point but I can't call the question anwered!
- 10/03/2011 at 8:22 am #6484
This issue is something that we could not reproduce in house.
Multiple members of our team tried using different settings/machines/environments. All attempts have failed.
The positive thing is that you don't experience it anymore.
No worries about marking the question as answered.
You must be logged in to reply to this topic.