search

dbouwman / solution-plan

1 stars 3 forks source link

Solution Lineage #7

Open chris-fox opened 3 years ago

chris-fox commented 3 years ago

I am having a difficult time putting all my comments/questions into the github repo, so thought I would describe here.

Today we have are already leveraging a pattern to determine the template a solution was created from, its version, and the source item an individual item was created from. Below is what we have:

// Example for a Solution Template
{
  ...
  typeKeywords: [
    “Solution”,
    “Template", // Specifies the solution is a template
    "solutionid-3ef", // ID of the template
    "solutionversion-1.0.0" // Version of the template, using semver
  ],
  ...
}
// Example of Deployed Solution Instance
{
  ...
  typeKeywords: [
    “Solution”,
    “Deployed", // Specifies the solution is an instance, deployed
    "solutionid-3ef", // ID of the template it was deployed from
    "solutionversion-1.0.0" // Version of the template it was deployed from
  ],
  ...
}

We use the ID and Version to determine if an update is available and notify the user in the UI that a new version of the Solution is available.

// Example of Deployed Item
{
  ...
  typeKeywords: [
    "source-87c" // original item id 
  ],
  ...
}

What we don't have is a way to connect the Deployed Item to the Solution Instance it is associated with and the Solution Template it is created from. The issue I see with the proposed design is as discussed yesterday a deployed item can be associated with multiple Deployed Solution Instances, via the reuse already deployed items logic. So a single typekeyword won't work in this case,

I would propose we create a new Portal Relationship type 'Solution2Item' that we can create between the Deployed Solution Instance and its related Deployed Items. The ArcGIS Online team was open to this, we just never full pursued it.

We could then write the "solutionid" typeKeyword to the Deployed Item to associate it to the original Solution Template it was created from because it can only be created from one template.

@dbouwman, @MikeTschudi

dbouwman commented 3 years ago

@chris-fox first off - I will switch our typekeywords to use the same format you are using today

As far as relationships, we've been asking the portal team (for years) for a generic item-to-item relationship, that does not require edit privs to either item, and has no cascading removal policies - just a simple-as-possible means to say A and B are somehow related... and apparently they are working on something that will be available in the spring... details limited... but that would definitely the best solution to this problem, as it allows 1:M.

That said, there is nothing precluding additional typekeywords...

{
 ...
 typeKeywords: [
  "solutionid-cc0", '// solutiontemplate
  "deployedsolutionid-bc4", // connected to this deployed solution
  "deployedsolutionid-ef5",  // connected to this deployed solution
  "source-43c" // original source item
 ]
...
}

I'd like to go this route near-term, as I would also like to implement a function that "cleanly removes" a deployed solution... having the multiple deployedsolutionid entries would allow us to "know" that although an item lives in the folder created by Deployment A, it is also used by Deployment B. So if we "remove" Deployment A, it should remove the keyword entry for that deployment, but leave the item.

Definitely "ugly", and would be much better handled via relationships, but unless the portal team can give us Solution2Item in, say a week, we'll need to have our own back-up solution.

The other snarly side of this is item ownership/shared edit access... although we can assume that all items created when a Solution is deployed, if the deployment is using some existing items... will the user have access to edit that item to add these keywords... if not, this may break. We could simply write the code in a fail-safe way... so if the current user happens to be able to edit the re-used item, it adds the keyword, otherwise, we just don't have that keyword, and may run into issues when "removing" deployed solutions...

or we denote in the data.outputs array of the deployed item that ef5 was not created by the deployment, thus it should not be removed.

chris-fox commented 3 years ago

In regards to the shared items between solutions, we are currently only searching the user's owned items to see if an item has already been deployed. So they should have the ability to edit their own items to add the typeKeyword. We did this out of experience because previously we would search for any item they had access to and this caused confusion to the user because we would reference a service deployed by someone else in the org that they had no knowledge of. So this shouldn't be an issue if we continue this approach.

In regards to the relationship, agree we haven't gotten much support for a generic Item2Item relationship, but they didn't have an issue with a Solution2Item relationship. Below is the original request, I just never pushed for it. I would like to update this request to make it more generic, remove the rules, etc. and push it forward. I don't see any reason we couldn't get in 8.4 and 10.9.

https://devtopia.esri.com/WebGIS/arcgis-portal-services-design/issues/14