2012-09-02

Using private Rhodecode repositories with Mantis BT

As you know you can use Mantis BT and Rhodecode in conjunction to keep your issues and code connected. However this only worked if you opened up your Rhodecode repositories (either GIT or Mercurial) for everyone to read. With the latest version (0.3.1) of the Rhodecode Mantis connector you can use Rhodecode API keys to have an authenticated user get the information needed by Mantis.

Update 29-12-2012:
Version 1.5.0 of Rhodecode changes the Raw-Changeset page. For interaction with Rhodecode 1.5.x you need version 0.4.0 of the Mantis RhodeCode connector

 Installation

  • Install the Source Integration plugin into Mantis,
  • To allow api access to private repositories you need to edit the Rhodecode source files.
  • Open the file changeset.py (Mine was located in /usr/local/lib/python2.7/dist-packages/RhodeCode-1.3.6-py2.7.egg/rhodecode/controllers/changeset.py)
  • Locate '@LoginRequired()' and replace it with '@LoginRequired(api_access=True)', save the file and restart Rhodecode
  • In Rhodecode allow a user to have read-only access to that repository (I added a Read-Only group with a Mantis user)
  • Go to the admin page for that user (via http://%rhodecode%/_admin/users) and note the api-key listed there
  • Install v 0.3.1 of the Rhodecode Mantis connector into Mantis
  • Open the Plugins configuration dialog for the plugin (via http://%mantis%/plugin.php?page=SourceRcWeb/config)

  • Insert the API key from Rhodecode into the API Key field
Now you can use the Repositories function for private repositories just like public repositories

2012-03-09

LabVIEW, web services and optional inputs

LabVIEW has an import web services module for several versions, and it’s quite a useful tool.

After an import your WSDL specification (the web service) has been translated into a .net library, and an accompanying LabVIEW library with proxy support.

The tool is pretty good and straightforward, but lacks one little detail: support for optional input that aren’t arrays or strings.

Optional inputs in web services are sent as a NULL object via the XML data, but that’s not working for booleans, timestamps and numerics since these data types have a valid value that can be null. In the web service definition (WSDL) this is shown with the following XML:

<s:element name="GetGlobalTable">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="from" type="s:dateTime"/>
<s:element minOccurs="1" maxOccurs="1" name="to" nillable="true" type="s:dateTime"/>
<s:element minOccurs="1" maxOccurs="1" name="highImpactCount" nillable="true" type="s:int"/>
<s:element minOccurs="1" maxOccurs="1" name="trainPassageID" nillable="true" type="s:int"/>
</s:sequence>
</s:complexType>
</s:element>



Elements that are nullable (arrays and string) have a minOccurs value of 0, data types that aren’t nullable have a nillable=’true’ field in the definitions.


The code generated by the web service importer for these nillable datatypes isn’t working ‘out of the box’:


NullableI32



Since the properties are read-only we can only read the value but not update, however the Nullable class is correct, so we need to recreate these classes.


The fix is quite easy (once you’ve figured it out):


WorkingNullable


This is a snippet from a VI dedicated to generate a nullable I32. With a parameter we decide whether the object is NULL, if that’s the case we just output a constant NULL.


If the parameter isn’t optional we use the LabVIEW supplied ‘To .Net Object’ to generate a basic .NET object, that we upcast to a Nullable of the appropriate type. The output is feeded into the .Net method for getting data.


This method works the same for booleans and timestamps.