Goal: deprecate Angular Admin app asap.
- current admin ui's and ux are sufficient
- main change is that "Data Manager" will be a top-level concern
- Documentation link in header is not i18nd - needs to link to the translated documentation 10606
- Graceful IE8/IE9 Degradation Messages 7896
| Current Route | /signin |
|---|---|
| New Route | /signin |
Since this app will be hosted in *.arcgis.com we can use iframed oauth, acting as the arcgisonline application. This will allow transparent sign-in via the esri_auth cookie, so users can seamlessly move between Admin and the Home app.
If we want to support a /admin route on custom domains, we need to make that decision asap, and discuss w/ the rest of AGO, as it will prevent users from seamlessly moving between the Open Data/Hub Admin and the rest of AGO.
| Current Route | N/A |
|---|---|
| New Route | /home |
I believe we want this page to be calls to action based on the user's identity. For v1, let's have this be an intro to the new Admin - maybe with a welcome video and links to "how-to" blog posts? Either way, having some static content on this page is an easy first step, and we can slowly migrate into role-specific calls to action.
| Current Route | /sites |
|---|---|
| New Route | /sites |
This is the entry-point to the CRUD for Sites. All UI/UX expected to be the same as Angular
| Route | Desciption |
|---|---|
/sites |
List of sites |
/sites/create |
start wizard to create new site |
/sites/:id/config |
basic site configuration |
/sites/:id/capabilities |
enable/disable per-site capabilities |
/sites/:id/groups |
add/remove groups from this site |
/sites/:id/layout/edit |
layout editor |
/sites/:id/layout/create |
site layout template chooser |
- Site List will not have link to "Data Manager"
- Site list will not have DCAT import integrated (it will be in the UI, but a link to
/integrations/dcat- see below)
- Vecor Basemap Error Message Appears Unexpectedly #10098
- Group Manager Image Services should be listed in pop-up #10219
- Group Manager should show all Open Data groups #7817
- Group Manager search does not find some groups #11409
| Current Route | /sites/:id/datasets |
|---|---|
| New Route | /data |
This will be a new top-level route hosting the UX for dealing with dataset & item status.
Of all the areas of the Admin app, this should likely have the most new work done, as there are many issues with the current UX
| Route | Desciption |
|---|---|
/data |
List of Actions to take, basically some prioritize list that are links to deeper routes |
/data/datasets |
list of datasets w harvest status, warnings, option to re-harvest |
/data/datasets/:id |
dataset details, option to re-harvest |
/data/items/:id |
item details, with some editable fields, option to reharvest |
- i18n'd dates in item/dataset lists #10995
- Html Entities in Titles are displayed #10626
- Re-Harvest Infinite Spin is confusing #9086
- View in ArcGIS.com always https
- web-sockets for harvest process status (req work on harvesters and admin ui)
- bulk actions from list views
- assign license
- re-harvest frequency
- item detail should have option to "Explode" multi-layer items --> single-layer items
- dataset detail should have option to initiate a "sync-to-online" process
| Current Route | /settings |
|---|---|
| New Route | /settings |
Currently this page pulls information from AGO Org, but saves changes to the Open Data API. As per comment the Ember version should read/write the AGO Org Settings.
However, the Portal Object is missing the following fields used in the Organization Information UI:
- homepageUrl (if different from the Portal Url)
- contact name
- contact phone
We need to decide if we drop these, keep them and store in a) our API, b) an item
- Org Summary Length Validation incorrect #8740
- Org Summary should show that the Org is not Public w/ option to change #8944
- Org Summary should update Org Profle @ AGO #10297
Currently this is done as a modal from the /sites route - but it's complex, and should likely be part of a broader "data integration" area of the app.
If integrations is not approprite, suggest a different name.
| Current Route | N/A |
|---|---|
| New Route | /integrations/dcat |
| Current Route | N/A |
|---|---|
| New Route | /pages |
This is a new area of the admin app, and while the basic functionality is pretty clear, many questions remain (see below).
| Route | Desciption |
|---|---|
/pages |
List of pages |
/pages/create |
start wizard to create new site |
/pages/:id/edit |
page editor |
- we need concise names to differentiate between "Org Curated Pages" and "Rando Public Pages", if only for internal communications.
- How are Pages associated with sites?
- Page picker UI like the Group UI?
- ETA for having a Page Item type at AGO? or do we proceed using App Config items w/ tags?
- Public Pages show the "Owner" at the top - do we want that same UX for Org Pages?
- Public Urls for "Org Pages"??? User Pages are
/username/pages/:idshould org pages also be/username/pages/:id? If so, when another Org user edits a Page do we update the username? or just stick w/ the original owner? - Is there an expectation that an Org Admin can see a list of all pages that use data owned by the org?
- Is there an expectation that an Org Admin can delete/hide etc a Page created by a public user? #10485
Basemaps and 1.x Sites
The current basemap choosing system has a lot of undue complexity because we dig into the "custom basemap webmaps" to check for custom projections, vector basemaps etc.
From an Engineering perspective, we'd like to change to using "basemap webmaps" to "boot the map" in
opendata-ui, thus significantly streamlining the basemap picking experience.However, the 1.X sites still need this capability... and the wonky basemap configuration. This gives us two options:
a) duplicate the existing logic in a 1.x specific component for the basemap picker (ick)
b) re-host the Angular admin app at
/admin-v1/(double-ick)Clearly option a is preferable, but it needs to be factored into the dev't timeline
Sites as Items
In considering storing Sites as Items, a few things came up which seem to be blockers
At the very least, it seems that we need the subdomain/custom domain information in a datastore that's local to rails. Unless someone has alternative ideas here, our plan it so continue storing Sites in Open Data.