Comment

I'm curious if I'm doing something wrong. For the findRelation URL, do you support multiple parameters both containing different types?

For example, building an Isilon plugin, the relationships work as follows:

The host contains access zones. Access zones contain SMB shares. SMB shares contain permissions. I have the relationships set up as follows via the plugin generator:

IsilonHost (root object)

     accessZoneFolder

          accessZone (GET /platform/1/zones)

               smbShareFolder

                    smbShare (GET /platform/1/protocols/smb/shares?zone={accessZone}

This works great. However I'm having trouble when trying to create permissions. The permissions object is actually returned as part of the share so the properties of a share in the plugin is a raw JSON string containing the permissions. I'm right clicking "smbShare" and selecting the option to create a new type. In order to create a relationship for permissions for each share, the findRelation URL would need to look like the following:

/platform/1/protocols/smb/shares/{smbShare}?zone={accessZone}

It appears that the plugin examines the first parameters OK but then I get an error in presentation:

2 errors - [findRelation URL], URL contain unknown type accessZone

If I remove the {smbShare} parameter, it finds accessZone and I get no errors, but this will not work since I need the share name in the URL. Likewise if I remove the {accessZone} parameter it works, however it only works for the default zone since I am unable to add that query parameter. Looking at your action for findRelation, it appears it only accepts one parameter for parent type and parent ID and what I'm doing will not work.


Can you confirm this? Do you have any suggestions for working around this issue? I love the plugin generator and I'm trying to stick with it but it may be difficult for this task if the current version will not provide a mechanism for passing multiple URL parameters.


EDIT: it appears if I reverse the order the workflow stops complaining but that blows up my response. So it looks like you can use multiple parameters and multiple types provided that a parent object comes first in the URL and a child comes second. In my case:  /platform/1/protocols/smb/shares/{accessZone}?zone={smbShare} allows the workflow to update parameter dropdowns effectively but functionality this will not work. Wondering if reversing this would be an issue?