Real Issue Tracker

It's deliberately so. The reason it was built this way was to prevent two issues being accidentally added when people doubleclick the "Save" button. There's no way to prevent this other than to educate your users.

By the way, there is an option to prevent people from repeating the title of the issues. This can be helpful if you want to enforce peers in your team to enter descriptive titles with the issues. I added that feature once because we were having lots of trouble to do support when people kept adding issues with the title "CMS bug" all the time with only different description.

I understand your point about users hitting "Save" twice or more. BTW there are some nice javascript options available which grey out the button after it's pressed once. But of course not everybody has javascript enabled, in which case a backup server-side solution is still needed. In my opinion, having both the javascript and the server-side logic would be best.

Anyway, I'm seeing some cases in my company where it might be needed to allow posts with the same name/description (But different users/timestamp/files). What would be very cool, and this is my feature request of the day, is to give admins a choice to enable/disable this feature!

Thanks.

Mmh I'm realizing my feature request might not be very clear. It would be a check box in the admin section, which controls if the "anti-doubleclick" logic should be enabled or disabled.

One more message, sorry about that flood (but better than no feedback at all?).

In fact, it would be very nice if the anti-doubleclick logic was looking into ALL fields of the ticket, not just the name/description, to really decide if it's the same ticket. I'm thinking, user, categories, files (check MD5 sums), etc...

I'll look into make the anti-duplication check all fields rather than just title+description. I don't think I'll have the time to add your feature request. In fact you can probably hack it yourself.

It already checks title, description, sections, type, urgency and (if applicable) email message ID.

Ok thanks, that's good to know. An MD5 hash comparison would be real cool as well, but don't worry if you don't have the time!