You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When executing retrieve, the first step of the process is to get the retrieve plans by calling the API https://<redacted>.skuidsite.com/api/v2/metadata/retrieve/plan.
This issue is not present during GetDeployPlan via API https://<redacted>.skuidsite.com/api/v2/metadata/deploy/plan. The JSON returned for sitepermissionsets matches the structure expected by NlxMetadata (a JSON array of strings).
The JSON looks like this - note that sitepermissionsets for skuidMetadataService is a valid JSON array of strings, while the sitepermissionsets for skuidCloudDataService is a JSON array of objects:
When ExecuteRetrievePlan is sent, the JSON above is marshalled as-is meaning the server is receiving the array of objects for sitepermissionsets for skuidCloudDataService.
In short, it's unclear what is or isn't working as expected since it's known from other issues in this repo that when the server gets payload it doesn't expect, it is prone to just skipping it rather than returning an HTTP 400. What is clear, however is that this could lead to unexpected behavior and one of the following must occur:
Either the /api/v2/metadata/retrieve/plan API is returning the result in an unexpected format and it needs to be fixed; OR
It's an expected format and the CLI needs to be adjusted to properly handle the different formats of sitepermissionsets between skuidMetadataService and skuidCloudDataService
When executing
retrieve, the first step of the process is to get the retrieve plans by calling the APIhttps://<redacted>.skuidsite.com/api/v2/metadata/retrieve/plan.The JSON returned from the API for skuidCloudDataService does not match the expected structure defined by
NlxMetadatafor the SitePermissionSets property.Note
This issue is not present during
GetDeployPlanvia APIhttps://<redacted>.skuidsite.com/api/v2/metadata/deploy/plan. The JSON returned forsitepermissionsetsmatches the structure expected byNlxMetadata(a JSON array of strings).The structure looks like this:
The JSON looks like this - note that
sitepermissionsetsforskuidMetadataServiceis a valid JSON array of strings, while thesitepermissionsetsforskuidCloudDataServiceis a JSON array of objects:{ "skuidMetadataService": { "type": "metadataService", "url": "/metadata/retrieve", "metadata": { "authproviders": [], "componentpacks": [], "dataservices": [], "datasources": ["PostgreSQL", "SkuidSample_NW_OData"], "pages": [ "SkuidSample_NW_Advertisements", "SkuidSample_NW_Employees", "SkuidSample_NW_Master", "SkuidSample_NW_Products" ], "designsystems": ["SkuidSample NW"], "files": ["NPNSwtvK_400x400.jpg"], "apps": ["SkuidSample"], "sitepermissionsets": ["Admin", "Public", "Standard"], "site": ["My Site"], "themes": [], "variables": [], "permissionsets": [], "sessionvariables": [] } }, "skuidCloudDataService": { "host": "gateway-us-rancher.skuid.net", "port": null, "type": "dataService", "url": "/metadata/retrieve", "metadata": { "apps": ["SkuidSample"], "datasources": ["PostgreSQL"], "sitepermissionsets": [ "{\"name\":\"Admin\",\"dataSources\":[\"PostgreSQL\",\"SkuidSample_NW_OData\"]}", "{\"name\":\"Public\",\"dataSources\":[]}", "{\"name\":\"Standard\",\"dataSources\":[]}" ] }, "appSpecific": false } }When
ExecuteRetrievePlanis sent, the JSON above is marshalled as-is meaning the server is receiving the array of objects forsitepermissionsetsforskuidCloudDataService.In short, it's unclear what is or isn't working as expected since it's known from other issues in this repo that when the server gets payload it doesn't expect, it is prone to just skipping it rather than returning an HTTP 400. What is clear, however is that this could lead to unexpected behavior and one of the following must occur:
/api/v2/metadata/retrieve/planAPI is returning the result in an unexpected format and it needs to be fixed; ORsitepermissionsetsbetweenskuidMetadataServiceandskuidCloudDataServicePlease advise.