Bug 1000743

Summary:	External trackers should enforce regexp patterns on external bugs
Product:	[Community] Bugzilla	Reporter:	Daniel Fisher <dfisher>
Component:	Creating/Changing Bugs	Assignee:	Simon Green <sgreen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.4	CC:	ebaak, jmcdonal, rjoost
Target Milestone:	4.4
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	4.4.0009	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-04 00:46:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	909791
Bug Blocks:

Description Daniel Fisher 2013-08-24 20:50:48 UTC

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 23:01:50 UTC

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-28 03:14:58 UTC

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-28 03:28:15 UTC

(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 13:14:30 UTC

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.

Comment 6 Simon Green 2013-09-19 13:27:49 UTC

(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-04 00:46:06 UTC

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