Bug 1000743 - External trackers should enforce regexp patterns on external bugs
External trackers should enforce regexp patterns on external bugs
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
4.4
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Simon Green
tools-bugs
:
Depends On: 909791
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-24 16:50 EDT by Daniel Fisher
Modified: 2014-10-12 18:51 EDT (History)
3 users (show)

See Also:
Fixed In Version: 4.4.0009
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-03 20:46:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Fisher 2013-08-24 16:50:48 EDT
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.
Comment 1 Simon Green 2013-08-27 19:01:50 EDT
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 2 Daniel Fisher 2013-08-27 23:14:58 EDT
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.
Comment 3 Simon Green 2013-08-27 23:28:15 EDT
(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.
Comment 5 Daniel Fisher 2013-09-19 09:14:30 EDT
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@redhat.com 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.
Comment 6 Simon Green 2013-09-19 09:27:49 EDT
(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.
Comment 9 Simon Green 2013-10-03 20:46:06 EDT
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

Note You need to log in before you can comment on or make changes to this bug.