Bug 682933

Summary:	Make BZ to SFDC integration fully configurable via cfengine
Product:	[Community] Bugzilla	Reporter:	Scott Dodson <sdodson>
Component:	Administration	Assignee:	Simon Green <sgreen>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.6	CC:	dfisher, ebaak, sdodson, sgreen
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-11 00:09:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Scott Dodson 2011-03-08 03:08:01 UTC

We need to refactor BZ to SFDC integration to allow for easier changes to the Salesforce.com parameters in dev environments.

Username will always be indicative of of the environment in question. Passwords for each environment can be different, however they're all currently the same.

DEV   = bzautomation.dev
QA    = bzautomation.qa
STAGE = bzautomation.stage2
PROD  = bzautomation

The hostname of the SOAP endpoint can change regularly in DEV, QA, and STAGE. We know that the hostname exists in the following files located in extensions/ExternalBugs/lib/Type/:

SFDC/BugWebServicesDEV.wsdl.xml
SFDC/BugWebServicesQA.wsdl.xml
SFDC/BugWebServices.wsdl.xml
SFDC_DEV.pm
SFDC_QA.pm
SFDC.pm

Additionally there's reference to the end points maintained in the following file which is auto generated on first invocation :

extensions/ExternalBugs/lib/Type/SFDC/BugWebServicesService.pm

Finally, we need to make provisions for the External Tracker system ID to be maintained across database reloads since this is how Salesforce.com indicates to Bugzilla which external tracker to create.

Comment 3 Scott Dodson 2011-06-22 13:49:35 UTC

Simon,

First it's worth clarifying a few points. Our production instance is na7.salesforce.com and it should stay that way for the foreseeable future. All non production instances are what are called Sandboxes and those can move around everytime we refresh them. You can authenticate against login.salesforce.com for production or test.salesforce.com for sandboxes.

1) So that's an interesting thing. When you log in it should pass back a new URL to you which will reference the actual host you need to issue your commands against. However, in the bugzilla code you're explicitly resetting that for some reason. See line 104 at http://svn.devel.redhat.com/cgi-bin/viewvc.cgi/bugzilla-rh/trunk/extensions/ExternalBugs/lib/Type/SFDC.pm?annotate=2282

I don't think that's necessary, and if we could get rid of that we could probably end up with just one type provided we can pass in three parameters Username, Password, and Auth URL (login.salesforce.com vs test.salesforce.com). After that's done as long as password for the user never changes there should be no reconfiguration.

2) The same would happen in sandboxes too if you're authing against test.saleforce.com. If you're going directly to the instance you're using it'll be the same.

3) Really depends if we address what I mentioned in 1).

Comment 7 Scott Dodson 2011-06-28 22:00:12 UTC

Patch looks OK to me, I have tested all features that we can test from bz-web2 and they work. Since this machine isn't accessible from the internet there's some features that we cannot test until they're in partner-bugzilla.

Comment 9 Simon Green 2011-07-11 00:09:22 UTC

This change went into production release last Thursday (July 7th) EDT.

  -- simon