Hide Forgot
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.
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).
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.
This change went into production release last Thursday (July 7th) EDT. -- simon