Signing into another org shows the same mmpks like arcgis.com

[codergrl]

Signing into another org shows the same mmpks like arcgis.com. Shouldn't signing into an org only display the mmpks belonging to that org? So, runtime.maps.arcgis.com should only show the runtime mmpks? @zinfin @mikewilburn thoughts?

[singhgag]

I suppose this is not app specific. I am just showing the results I get back from the portal.

[mikewilburn]

This was my experience as well @singhgag. Are we doing something like filtering for more than just .mmpks? I recall seeing what appeared to be premium streetmap content for different countries and even US states that was coming back from outside the org.

[singhgag]

There are only two filters used in the query for portal items.

1. type should be MobileMapPackage
2. search string if provided

[mikewilburn]

Are you making sure to constrain the query to be specific to the org as well? Consistent with what's offered by this toggle on the UI?

See the orgid item field here: http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#/Search_reference/02r3000000mn000000

[singhgag]

I am not. If you look at the documentation here, it mentions

A user of the Portal (and of the REST API) sees the view off the Portal that applies to their organization subscription. This view includes users, groups and items that belong to the organization and have been shared with them. This view may also include users, groups and items that are external to the organization and have been shared with the user.

The other packages you see are public (I suppose), so shared with the user. Thats why you see them.

[mikewilburn]

I think we should @singhgag. Listing all publicly-available mobile map packages on ArcGIS Online or from other portals is of little help to the user in this app.

[singhgag]

@mikewilburn I would suggest we keep this as an enhancement for later. I am not sure if I will be able to take this with the other stuff left to complete. This would require a design change, implementation and test effort.

[mikewilburn]

@singhgag I can understand that if this is not a minute amount of effort, it should be postponed until after the initial release.

If @marastoica agrees, I'll log an enhancement, link it here, and close this issue. Or repurpose this issue? Which is better?

[codergrl]

@mikewilburn I don't think of this as an enhancement as the app isn't useful at the org level without this. However, given the timeline, we can release this app with this as a known issue and address it in subsequent versions of the app.