Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

item.update(item_properties={"typeKeywords': "values"}) fills in default values #1855

Open
FeralCatColonist opened this issue Jun 27, 2024 · 2 comments
Assignees

Comments

@FeralCatColonist
Copy link

Describe the bug
When providing an update to the typeKeywords key, if appropriate values are not provided, then a series of default values are inserted into the item's typeKeywords. These may be substantially different from the default values assigned during the item's creation. This can provide a number of unintended consequences, most notably with the Site Application item type where the lack of a hubsubdomain|some-site keyword effectively removes access to the site.

To Reproduce
Steps to reproduce the behavior:

# we assume here a variety of item types: Dashboard, Web Experience, Feature Service, Web Map, Site Application
source = arcgis.gis.GIS()
for item in itemid_list:
    source_item = source.content.get(item)
    print(f"{source_item.itemid} | {source_item.type} | {source_item.title} | {source_item.owner}")
    print(f"\ttypeKeywords: {source_item.typeKeywords}")
    print("\tupdating typeKeywords with 'TEST-keyword'")
    source_item.update({"typeKeywords": "TEST-keyword"})
    source_item = source.content.get(item)
    print(f"\ttypeKeywords: {source_item.typeKeywords}\n")

error:

c5b57fbdaeeb4973a8560c25119ec118 | Dashboard | bug - dashboard | some_user
	typeKeywords: ['ArcGIS Dashboards', 'Dashboard', 'Operations Dashboard']
	updating typeKeywords with 'TEST-keyword'
	typeKeywords: ['Dashboard', 'Operations Dashboard', 'TEST-keyword']

c709fad59c504db09823bb86f11ac4ae | Web Experience | bug - exb | some_user
	typeKeywords: ['EXB Experience', 'JavaScript', 'Ready To Use', 'status: Published', 'version:1.10.0', 'Web Application', 'Web Experience', 'Web Mapping Application', 'Web Page', 'Web Site']
	updating typeKeywords with 'TEST-keyword'
	typeKeywords: ['TEST-keyword', 'Web Application', 'Web Experience', 'Web Mapping Application', 'Web Page', 'Web Site']

70c702e1ed34496c938738a387b70aae | Feature Service | bug - feature layers | some_user
	typeKeywords: ['ArcGIS Server', 'Data', 'Feature Access', 'Feature Service', 'providerSDS', 'Service', 'Hosted Service']
	updating typeKeywords with 'TEST-keyword'
	typeKeywords: ['ArcGIS Server', 'Data', 'Feature Access', 'Feature Service', 'Service', 'TEST-keyword', 'Hosted Service']

3c7862694aed46bd9aa0a30947ddf532 | Web Map | bug - web map | some_user
	typeKeywords: ['ArcGIS API for JavaScript', 'ArcGIS Online', 'Collector', 'Data Editing', 'Explorer Web Map', 'Map', 'Online Map', 'Web Map']
	updating typeKeywords with 'TEST-keyword'
	typeKeywords: ['ArcGIS Online', 'Explorer Web Map', 'Map', 'Online Map', 'TEST-keyword', 'Web Map']

744dd182177f4c5f8f62f929c9d1b457 | Site Application | bug - site | some_user
	typeKeywords: ['Hub', 'hubSite', 'hubSolution', 'hubsubdomain|bug-site', 'JavaScript', 'Map', 'Mapping Site', 'Online Map', 'OpenData', 'Ready To Use', 'selfConfigured', 'source-embedded-portal-default-site', 'state:hasUnpublishedChanges', 'Web Map']
	updating typeKeywords with 'TEST-keyword'
	typeKeywords: ['Hub', 'OpenData', 'TEST-keyword']

Expected behavior
The current documentation is lackluster for those unfamiliar with using the ArcGIS REST API, when utilizing update my expectation is that it appends a singular value, and wholesale replacement of the values would require a comma separated list. This erroneous thought process was compounded by the fact that items continued to operate, returned a number of typeKeywords including the singular value that was provided. As stated above, this behavior was not fully understood until the Site Application became inoperative.

image image

A few thoughts,

  • first, this section in the documentation could be expanded to make this behavior more explicit / clear.
    -- developers.arcgis.com/python/api-reference/arcgis.gis.toc.html#arcgis.gis.Item.update
    -- a discussion on how update will remove all current parameters for a given key-value pair
    -- notes on default parameters being created (to try and prevent an item from becoming inoperative)
    -- example usage for the ingestion of list-based values
  • second, append/remove parameters could be added to the update function to allow more fine-grained control on the simple addition/removal of values.
    -- This would be a quality of life improvement to allow more pythonic operation instead of full replacement for what could be a single item addition/removal
    -- The current methodology for adding a value is a bit circuitous:
list_typeKeywords = item.typeKeywords
list_typeKeywords.append("some new keyword")
text_typeKeywords = ",".join(list_typeKeywords)
item.update({"typeKeywords": text_typeKeywords})
  • third, if the API is going to attempt to provide defaults, those ideally would match the typeKeywords generated at item creation

Platform (please complete the following information):

  • OS: Windows 11
  • VS Code
  • Python API Version 2.3.0.2]
@nanaeaubry nanaeaubry self-assigned this Jun 28, 2024
@nanaeaubry
Copy link
Contributor

@FeralCatColonist
Thanks for reporting this and being so thorough in the description! Going to take a look at this and get it sorted, Ill let you know of any updates

@nanaeaubry
Copy link
Contributor

@FeralCatColonist
I spoke with our sharing team about this behavior and they say it is expected and has always been like this... however I do see it being frustrating for apps when all the typeKeywords get eliminated and you lose functionality of that app.

We will look into an enhancement in the python code but since typeKeywords are added within the item_properties dictionary we cannot simply add an append or anything.

For now the workaround, albeit circular, is the best way to manage this occurrence. We will amp up our documentation around this as well.

@nanaeaubry nanaeaubry removed the bug label Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants