ArcGIS Pro could maintain layer field order and alias when sharing web layer with time zone specified

[TimMinter]

ArcGIS Pro 2.4.3 changes the field order when I "Share as Web Layer" and "Overwrite Web Layer" to an ArcGIS Enterprise 10.7.1 hosted feature layer.  Mostly, the end result are date fields ordered at the tail end of the field list with the field aliases stripped off.  This is truly annoying and causes duplicate work to monkey around with the pop-up field order and aliases.

As a general expectation, I want the entire ArcGIS web service publishing results to respect all of the configurations I make in the:

• source geodatabase field definitions, order, metadata, etc.
• ArcGIS Pro map and layers
• publishing configuration - e.g. if I set the time zone and daylight savings time, don't make me reset it every time I overwrite the service.  I believe I've had an idea about this kind of thing before.

Where's the link to that satisfaction survey?

tim

[KoryKramer]

Like Respect MXD field's order in MapService and FeatureService REST description which appears to have been implemented in ArcGIS 10.8.  I checked with ArcMap 10.8 (to an ArcGIS Online hosted feature service).

The data source field order was changed in the layer so that Date_Field3 is before Field2 which is before Field1.

This is what I see in ArcGIS Online:

The shape_area, shape_length and objectID fields are still ordered last:

In ArcGIS Pro 2.5, I see the layer order respected in the hosted feature service:

I checked with aliases too and those come through as expected:

[TimMinter]

Hi Kory,

How do we reset this idea to "not offered"?  Clue in bold italics...

ArcGIS Pro 2.4.3 changes the field order when I "Share as Web Layer" and "Overwrite Web Layer" to an ArcGIS Enterprise 10.7.1 hosted feature layer.  Mostly, the end result are date fields ordered at the tail end of the field list with the field aliases stripped off.  This is truly annoying and causes duplicate work to monkey around with the pop-up field order and aliases.

I upgraded to ArcGIS Pro 2.5, immediately smacked my head on this (BUG-000129031: In ArcGIS Pro 2.5, publishing a hosted feature layer.. ), used "language" out loud, and observed that ArcGIS Pro 2.5 continues to change field order for me when I don't want it to, and refuses to change field order for me when I do want it to (ArcGIS should allow the ability to permanently reorder fields in a table).

How to reproduce: 

• make a file geodatabase feature class
• add a date column somewhere in the front of the column list
• share as web layer > Feature Layer > copy source data to AGE
• specify the time zone and daylight savings time
• publish to ArcGIS Enterprise 10.7.1.
• Ta-dah, ArcGIS Pro mangles the field order, alias, and column name.

I notice that the Convert Time Zone GP tool offers the same results, so that's probably a clue for whoever didn't get the design principle message that ArcGIS does not change field order.

Cheers,

tim

[KoryKramer]

Hi Tim,

In my comment above I noted that the fix is in ArcGIS 10.8.

Your steps indicate you are publishing to ArcGIS Enterprise 10.7.1.

Below I published from ArcGIS Pro 2.5 to ArcGIS Enterprise 10.8.

Is that what you expect to see?

[TimMinter]

Hi Kory,

Well, bummer.  Nope, my idea remains quite valid in my opinion.  I found an ArcGIS Enterprise 8 environment that I could test with.  Getting into a little computer science here...

• hypothesis:  Kory is right and Tim is wrong
• test:  using WA-DNR's county boundaries (WA County Boundaries ) as the source feature class, import it to an ArcGIS Pro 2.5  file geodatabase, then share as web layer to an ArcGIS Enterprise 8 deployment.  Check the position and name of the date column before and after.  If the position and name of the date column has changed, then the hypothesis is disproven.
• results:  hypothesis is disproven

[KoryKramer]

Is the edit_date an editor tracking field?

[TimMinter]

Not in context of the ArcGIS Pro "Enable Editor Tracking" or ArcGIS Enterprise "Keep track of who created and last edited features" capabilities.  The field could have been named "TimTestDate" and my hypothesis is that it would have been shoved to the back of the list and renamed "timtestdate".

The same thing happens when using the Convert Time Zone GP tool, so I hypothesize that the "share as web layer" function calls the GP tool, uses its code, or is similar in some other way.

[KoryKramer]

Interesting!

So I DO see what you see when I follow the steps that you provided.

Here is the difference in the testing that we were doing independently: since the idea was about changing field order, I had been changing the field order of the layer in Pro before sharing.  And even when the Time Zone was set in my tests, I never saw it result in sending the date field to the end of the table.

Since I was finally able to reproduce what you see, given that I knew what I had tested previously, I decided to change the field order of the layer in Pro before sharing.  When I do that, even with the Time Zone set (in this specific instance, I didn't check the Daylight savings box), the field order of the layer and the alias are maintained.

Then, even if I just use the Reset Field Order command to revert the layer's field order back to the database order:

publishing the layer still maintains the expected field order and does not alter the alias.

To demonstrate the repro steps you've outlined, if I remove the layer, and add the feature class back to the map and do nothing to the layer order, publishing results in the date field being moved to the end of the table with a different alias.

Given that, if you want to keep this as an idea open to voting by the community, a more descriptive title might be, "Maintain layer field order when sharing web layer with time zone specified"  Seems like a very niche case for an idea, though.

If you agree, I could update the title and change the status back to (thoroughly) Reviewed.  Or if you'd prefer to update the title, you can do that and then ping me to reset the status.

Thank you!

[TimMinter]

Hi Kory Kramer‌

I agree.  Please change the title to "ArcGIS Pro could maintain layer field order and alias when sharing web layer with time zone specified" if it has any chance of fitting and reset the status.  I don't think it's a niche idea.  I also think it fits squarely within the "Esri could provide an integrated, consistent, and reasonably good quality ArcGIS Platform" idea.

Thanks,

tim

[RichardHughes2]

Hello Korey and Tim,

I ran into this issue today and will follow your steps to reorder Fields in Pro and republish. 

What I am doing is joining a table to a feature class to create a target schema with empty join fields then publishing to Pro 10.8.1.  I am using the fields aliases from the hosted layer to match to the field aliases after converting Excel to Table and updating the hosted layer with the records from the table.  

If I understand correctly, simply reordering the fields in Pro will do some magic and they will publish correctly?  Is this a documented bug that can be fixed in Pro?