nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Allow adding fields to AGOL hosted layer with dependent JOIN

JayJohnsonWashoeCounty

The inability to ADD fields to hosted feature layers on which you have created a dependent view using the JOIN Analysis tool is a big problem. The requirement to delete the hosted view, then re-create it, generates tedious re-building work in all dashboards that the layers are used in. Please provide some kind of workflow to make adding fields in this situation less problematic.

One idea is to create a tool to allow easy re-pointing of dashboard components to a new URL (the new URL of the hosted view that has to be re-created).

Alternatively, some way to "suspend" the hosted view, add fields to the hosted layer, then "refresh" the hosted view from the updated layer would also be great.

Thanks.

Jay

Encontre mais publicações marcadas com

Status: Abrir

Comentários

MappyIan

I can't believe this idea was first logged six years ago and still hasn't been addressed by Esri. We really need the ability to add fields to hosted feature layers that are configured with joined views. Having to delete the joined view, add the field, recreate the joined view, then repair all maps/dashboards/apps etc. is a massive pain in the neck.

TomReyes

The fact that we cannot do this is a major issue. I have to rebuild multiple Experience Builder pages just to update a domain or add a field.

MarkWILSON_LLS

+ 1.
This makes so much sense from a data management perspective. ViewJoins are theoretically best practice for data upcycling.

Allowing ViewJoins to mash hosted features together without merging into a new dataset and consuming 'extra credits' (Melvin's voice from Captain Underpants)

Processes

- have some form of pause functionality on the parent layer(s) or on the entire AGOL acct to suspend Views using the parent layers

- this would unlock the schema allowing changes to be made

- unpause/re-activate the service

- refresh function on the VIEW Join layer to allow schema updates (additional/deleted fields) to flow through effectively.

- either a script or inbuilt GUI function to advise of all the affected end products where the schema has flowed through to.

- where a end product (map, app, ExB, Dashboard) is affected, A review popup window opens warning of the schema update and asks for immediate rectification (ie if the symbology, labels, popups, filters were affected by a deleted field) they could be fixed straight away..

Go on ESRI. I know you can do it!

thanks

PanGIS

I have a complex dashboard made of multiple protected views and I have to delete everything just to add a field...

MattyMaps

can we get this on a implementation roadmap?

EleanorDhuyvetter

Would LOVE this to be solved. Running into an issue with wanting to add questions/fields to an operational survey which has joined views from the surveys FL. A solution to this would make the workflow so much smoother, without creating multiple FLs/joins every time we want to update the survey.

patrickb

This request might get more visibility/traction if it gets moved to the more general ArcGIS Online channel, as ArcGIS Dashboards is not in charge with how schema changes are made/handled. Please note, there are existing ideas in that channel that seem to be related to the same core problem (example).

Aside: The secondary idea (to expose an ability to allow easy re-pointing of dashboard elements to a new data source) is legitimate, but would not address the real pain point expressed here, which is having to go back and re-configure all dashboards (and other apps) that had referenced the view. With that in mind, if you want the Dashboards team to track/consider that, please submit a second idea.

MargrietdePender

This would be a good improvement.

We created a join view layer and we ran to exactly this issue.

RobertAnderson3

Definitely see this as an important improvement.

I've been working with Survey123 and creating dashboards to display that data, as soon as there's a repeat section in it I've been adding the join to display the data in the dashboard.

Took way too long to figure out this was why the survey wouldn't publish when I added a field earlier. (Survey123 really needs some feedback messages when publishes hang)

TijsLips

Waiting for this update for years now.. It is hard to explain to my colleagues when they ask for an extra attribute field, and I have to sell no to them. Fully agree with your thoughts @RichardHoweRSKECO

RichardHoweRSKECO

I can't believe that:

1. This idea hasn't got more traction

and

2. It's not been addressed regardless.

I understand the need to lock the modification/deletion of fields that are literally required for the join, but I fail to see why adding extra fields to the parent layer is blocked. It's massively frustrating and causes a ton of extra work!

All it leads to is people duplicating geometry information in mutliple layers, when the more correct way to do it would be to have a single source of truth for geometry and hang all the information from it in hosted views.

erica_poisson

If this idea ever got implemented, I think it would save many people lots of time in re-configuring web maps, apps or Dashboards that contain "joined view layers" if a hosted feature layer schema needs to be updated.

JMitchell

This is exactly the functionality that I could really use at the moment. I have a hosted feature layer that I am using to conduct field data collection which has several different asset tables related to it and I have been using view layers created through the JOIN Analysis tool in order to show information from the various related tables on the map through labels and symbology...however, I need to add a few fields to one of the related tables which means I have to delete the several view layers, add the new fields to the parent dataset, recreate the views, recreate all the label logic and symbology, then add the new view layers to the map.

If I had the layers exposed in any dashboards or webapps, that would add an extra layer of tedious, time-consuming (and wasted!) work just to simply add one or two new fields to a single table.

I sincerely hope that some option to suspend the lock on the parent feature of any views using joins will be seriously considered!

KevinMacLeodCAI

agree +1

Participe da Conversa

Faça login para postar, seguir conteúdo e mais. Novo aqui? Registre-se gratuitamente.