Include dependent_to() and dependent_upon() support for ArcGIS Online within the ArcGIS API for Python.

[AbrahamDowner1]

Include dependent_to() and dependent_upon() for ArcGIS API for Python are available for Enterprise and Portal. Please make this available for ArcGIS Online. There is vastly more content created for our AGOL organization that needs to be evaluated for deprecation than Enterprise. 

[GeorgieCassar1]

I agree.

I really need this on AGOL.

If there's a workaround, please let me know.

[OderMarcusWCED]

From my experience maintaining an in-house Python Portal Item inventory script using arcgis.gis 2.3.0 library that runs against our internal 10.9.1 Portal and our AGOL portal since 2021 I have these observations:

dependent_upon() method only apply to Enterprise (as documented somewhere) - and even though some basic items return results for these methods they only seem to be very simplistic relationships. For instance it seems like Feature Service, Geocoding Service, Geoprocessing Service, Map Service all return a dependency on our Server (surprise!). For Web Maps dependencies are about what you would want, For Web Mapping Applications there are some urls and item ids - but probably not as fleshed out as you'd expect. Method does not return anything for the lone Dashboard we have in Enterprise. For this reason I don't think as currently implemented dependent_upon() at this time would be useful in AGOL. As for dependent_to() method - I think the relationships just aren't there to instantiate this object in as in essence you would have to know all dependencies in advance which would add even more bloat to the item object.

Our workaround for getting dependencies is something like this:

1. Do your Inventory with home brewed Dependency
   1. Establish Portal connection with Admin privileges
   2. Search the entire Portal for all items and get master list of item ids and item types in your portal
   3. Iterate by item type and id through items and if item type supports content and content is of type dictionary:
   4. Iterate through nested dictionary of content and look for keys of webmap, itemID, url and add to a flat array / list / dictionary for that item.
      1. For returns of itemID, and webmap you can check that string returned is 32 characters long and consists of only digits 0-9 and lower case alphas (i.e. an id that looks to be a portal id not some other kind of id.
      2. There are a few objects that seem to be self-referenced like some of our old WebApps - if one of the ids or urls returned is the same as item.id or item.url you can leave it out of dependency
   5. Write results somewhere - should be an array with same number of rows as items in portal with minimum columns of item.id, item.title, item.type and Dependency array.
2. Post Process step to create known Parent Dependencies
   1. Take the inventory list and for each item.id and item.url:
      1. Search the Dependency array column for all other items that contain either item.id or item.url of current row and add to a flat array / list / dictionary for that item which represent the parents of current item.
   2. Write results somewhere - should be same array as in initial inventory with additional column of parent dependencies
3. Keep an eye out for known relationships that don't appear in either Dependencies or Parents and tweak content search of dependency keys being searched for (can be customized for a particular type for instance). I'm sure that some of the way our Apps are nested within other Apps are getting missed due to how embedding was accomplished.
4. Our implementation can only really can calculate Parents for items in a common Portal - would probably fail if portal id found is really referenced in another Portal. Well not fail exactly - it just would not show up in the Parents list