SFDC casenumbers should be 8 numbers long. 2 of those numbers (as of the time of this writing) are zero-padding. So, some folks will remove that zero-padding and think (justifiably) that 123456 is the same as 00123456 But it isn't. And SFDC isn't updated. And the External Tracker doesn't have accurate information (because as far as SFDC is concerned, it's pointing at a non-existent casenumber) The best implementation would allow folks to continue to enter a six digit casenumber and then it just zero-pads to 8 digits automagically.
I'm going to widen this bug so that all external trackers can have regular expression matching for validation. When working on another (never completed) bug, it was clear there was a lot of invalid input in other types. Changes: * A list of valid regular expressions (and a string describing them) will be stored in the config.yaml file. An example is the regular expression /^\d{8}$/ will have the string '8 numbers'. * A new column will be added to the external_bugzilla table that stores the regular expression (if any) for each type * The admin pages will be changed so FLS can set the regular expression for each external bug tracker. * Write an SQL script to update the existing external trackers with the regular expression to use. * When adding a new external tracker (either via RPC or the UI), a check will be made that the external bug id matches the regular expression. An error message will be displayed if it isn't * Add a hack so users that enter SFDC types ids with less digits have the value left zero-padded.
Comment 1 certainly seems to be on the right track. I think there's a *little* bit more nuance for that last bullet point, however. This Bug: https://bugzilla.redhat.com/show_bug.cgi?id=891885 has an external tracker of Red Hat Customer Portal Casenumber=1 I think there probably needs to be a bit more logic for the zero-padding (some minimum value perhaps? 10000, maybe?) to avoid '1' being received as a valid value.
(In reply to Daniel Fisher from comment #2) > I think there probably needs to be a bit more logic for the zero-padding > (some minimum value perhaps? 10000, maybe?) to avoid '1' being received as a > valid value. I have no objection with that.
I don't know how much (or whether) this complicates the pursuit of this bug, but I've been seeing a bunch of (at least two) bots erroneously clone bugs, and trim the zero-padding from the External Trackers. e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1009052 BTW- The rhev-integ email has been notified about this misdeed (and is investigating a fix). I'm hopeful that when this RFE is fixed that client-side trip-up won't even be possible.
(In reply to Daniel Fisher from comment #5) > I don't know how much (or whether) this complicates the pursuit of this bug, > but I've been seeing a bunch of (at least two) bots erroneously clone bugs, > and trim the zero-padding from the External Trackers. It doesn't complicate it at all. With the change I wrote tonight, you will not be able to create a bug with an invalid external tracker id (and for SFDC ids, it will automatically pad numbers less than eight digits with leading zeros). Tomorrow I'm working on a Javascript change, so you can see the error before submitting the form and getting the big red error box. Obviously for RPC calls, you will simply get an error.
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug. -- simon