|
IDEA
|
If a value of a field is the 'description' of a domain instead of the code, both the Attributes Table and Attributes pane will be unable to 'change' the invalid domain code (if it's the same as the description of a domain value), unless the value is switched to something else, and then can be switched to the valid domain choice. This is confusing to many users because they 'see' they already have the correct value from the domain pick-list, at least apparently. I am asking for a better visual indication / helpful warning / one-click-fix for users in this case to correct this issue from the Attributes pane. I will provide a common example: a domain with code 'Y' and a description of 'Yes': If the base values of the field with that domain applied is 'Yes' rather than 'Y', the Attributes Pane will show an error that 'Yes' is not a member of the coded value domain, but the pick-list available to them shows 'Yes' and when they select it nothing changes, so the user likely will be confused about what the problem is, unless they are veteran of domain issues and goes to the attribute table and turns off 'Show domain and subtype description' values and diagnose any non-'Y' values from there. The main "Idea" I'm proposing here could be something as simple as a warning that "your base value matches a domain description 'Yes', but is not the correct domain code value of 'Y'." Further: provide a one-click-fix functionality: "Do you want to update this to match the valid domain code 'Y'?" Maybe even further: "Do you want to update all values of 'Yes' in this table to the valid domain code of 'Y'?" IMO this is a very common issue, since sometimes domains are applied to data that is already populated with a 'description' value but the user defines a domain after the fact that uses a more simplified code value, or a code value with different character case than the description.
... View more
09-18-2025
07:57 AM
|
5
|
1
|
462
|
|
IDEA
|
Alright thanks, I will create the more focused idea as a new post.
... View more
09-18-2025
07:52 AM
|
0
|
0
|
985
|
|
POST
|
The parameters and parameter orders are different for arcpy.da.SearchCursor and the legacy arcpy.SearchCursor, but I see I think if you want to follow your previous coding style you could write a legacy SearchCursor like so: for row in arcpy.SearchCursor(dataset="layer"): print(row.getValue("OBJECTID") # note that it seems you must use row.getValue("field") rather than row["field"] like in your example ... If you want to use the equivalent code with arcpy.da.SearchCursor must specify fields that you want to return values for. This is different from the legacy SearchCursor. I didn't even realize the legacy method allowed you to not specify fields and instead row.getValue("field"). So that's a big change if you did not previously use cursors this way: for row in arcpy.da.SearchCursor(in_table="layer", field_names=["OBJECTID", "other_field"]): print(row[0]) print(row[1]) ... the more common practice is to use this format for cursors. If I'm not mistaken, this is more critical for UpdateCursor since you have to reference the cursor object to perform an update or delete method, e.g. cursor.updateRow(row): with arcpy.da.SearchCursor(in_table="layer", field_names=["OBJECTID", "other_field"]) as cursor: for row in cursor: print(row[0]) print(row[1]) ...
... View more
09-18-2025
07:32 AM
|
2
|
0
|
691
|
|
IDEA
|
@Scott_Harris Thank you for your quick response. I think these conclusions are only partly correct -- let's ignore the duplicate domain description issue: When no duplicate descriptions are defined in the domain, there is still the issue where if a value of a field is the 'description' of a domain instead of the code, both the Attributes Table and Attributes pane will be unable to 'change' the invalid domain code (if it's the same as the description of a domain value), unless the value is switched to something else, and then can be switched to the valid domain choice. This is confusing to many users because they 'see' they already have the correct value from the domain pick-list, at least apparently. I am asking for a better visual indication / helpful warning for users in this case for how to correct this issue from the Attributes pane. I will provide another example that is common: a domain with code 'Y' and a description of 'Yes': If the base values of the field with that domain applied is 'Yes' rather than 'Y', the Attributes Pane will show an error that 'Yes' is not a member of the coded value domain, but the pick-list available to them shows 'Yes' and when they select it nothing changes, so the user likely will be confused about what the problem is, unless they are veteran of domain issues and goes to the attribute table and turns off 'Show domain and subtype description' values and diagnose any non-'Y' values from there. The main "Idea" I'm proposing here could be something as simple as a warning that "your base value matches a domain description 'Yes', but is not the correct domain code value of 'Y'. Do you want to update this to match the valid domain code 'Y'?" Maybe even further: "Do you want to update all values of 'Yes' in this table to the valid domain code of 'Y'?" IMO this is a very common issue, since sometimes domains are applied to data that is already populated with a 'description' value but the user defines a domain after the fact that uses a more simplified code value, or a code value with different character case than the description.
... View more
09-18-2025
06:18 AM
|
0
|
0
|
1005
|
|
POST
|
Did you ever set up any external application/integration that previously authenticated with an AppID/secret? Maybe someone with privileges to create a new 'Application' under their user account attempted to set something up, had trouble, removed the application in Portal, but the <external thing> is still trying to connect? I wonder if there is nothing preventing any rando/service on the internet from attempting to authenticate with your Portal if it's exposed to the internet. I had a case in particular where an integration with our GIS through a secured feature service required us to create an AppID/secret for use by their cloud-based web config menu. At some point, something broke, and although it still requires us to enter the AppID, the 'actual' authentication happens via a popup window for Portal login in order to get the system to see the feature service. Before figuring out the method to get the popup login to show up, we would get exactly this format of login error showing the AppID as the 'username' everytime it tried to connect. I'm curious about this: a sign in error, for a service we cannot find in our Portal Are you saying you can see that this is trying to access a particular service? Or are you just saying you don't recognize whatever is shown as the 'username'? At least in my case, the errors you are seeing are 'normal' generic login warnings. lol @ my poor user trying to remember his credentials
... View more
09-17-2025
02:05 PM
|
0
|
0
|
671
|
|
IDEA
|
When a domain is applied to a feature class field that may already be populated with values that do not match a domain code, or if someone accidentally uses Calculate Field to apply a domain description value instead of a domain code value, ArcGIS Pro could make the users' life much easier in helping to diagnose and update values. Specifically, adding a functionality in the Attributes pane to be more helpful in cases where a 'base value' matches a domain description value would go a long way in quickly helping the user to see the issue. I have created an extremely basic example below (ArcGIS Pro 3.2.5) to illustrate the point. I have a point feature class with a TEXTFIELD1 that has a domain assigned. You will notice that CODE2 has the same description as CODE1. This is a slight aside to bring up the issue that you can have multiple domain codes with the same description. The user can't select both from attribute value drop-down... so it just defaults to the first one in the domain list I assume. Anyway, the super simple domain: The point features showing the domain description values: The point features NOT showing domain description values: Point 2 selected - the Attributes pane correctly warns that the attribute value DESCRIPTION1 is not a valid domain value. However, if you click the TEXTFIELD1 value pick list, and you select DESCRIPTION1, it will not update the base value to be the valid CODE1 domain value. It remains DESCRIPTION1. The only way to update the value to CODE1 is to flip the value to NULL (or some other domain value), and then choose the correct value; or, use Calculate Field and apply the CODE1 value that way. And just to follow up on that side-note about CODE2 having the same description as CODE1 - there is no way to choose a value that resolves to CODE2. Further, there is an inexplicably odd behavior where if 'Show domain and subtype descriptions' is off, the Attributes pane shows TEXTFIELD1 as the CODE1 value! What in the heck? What kind of sense are beginner or even intermediate users supposed to make of this? --- So after all that said -- what am I asking for? (main issue) Preferably, there would be updated behavior in the Attributes pane to help users resolve this exact issue. Whether there is an additional functionality in the Attributes pane that shows both base values of a field AND the domain description at the same time where users can directly 'override' whatever behavior is happening here; or better warning description that describes to the user how to switch the value to NULL (or some other domain value), and then choose the correct domain value. I'm not totally sure what this would look like in the end, but I'm just proposing there ought to be something that is more helpful. (side issue) Possibly require domain descriptions to be unique, the same way domain codes are checked for uniqueness? Maybe there are use cases that negate this... but if there are, they must be aware that they can't actually populate the secondary domain code through the Attributes menu/Attribute table if they do set things up this way, so I'm not sure what the point of that would be. (bug fix?) Fix the issue where a domain code description value entered as the base value shows up in the Attributes pane as the domain code value (when 'Show domain and subtype descriptions' is off). Is this a bug? Maybe fixed in other versions of Pro? In conclusion: this is not really a fringe issue - I have dealt with it myself many times, my users are confused by this issue, and I have had consultant (GIS professionals) I'm working with struggle with it and I have to explain it to them. EDIT: Additional note: I imagine this issue also affects users doing web map editing, and Field Maps. So if there can be functionality across the whole pipeline that helps users address domain value mismatch more easily, that would be great.
... View more
09-17-2025
01:36 PM
|
0
|
4
|
1112
|
|
POST
|
Glad to hear it, and you're not alone with having trouble with with situation of updating mis-matching values to for domains. It can be a pain. I think ArcGIS Pro could be much more helpful to the user to dynamically show both code and description values in the attribute pane to make sure you are clearly able to see the issue when it finds a value that does not match a domain code. Maybe I can submit this as an idea in the forum if it's not already there. I recently had to explain to a consultant GIS analyst this same issue when they provided a deliverable where almost all the feature values were 'description' values instead of the codes for the domains that they themselves set up. We had to go back and forth a few times and I had to explain it in a few different ways until it clicked and we got it all corrected.
... View more
09-17-2025
11:34 AM
|
0
|
1
|
499
|
|
POST
|
What I can tell from this screenshot is that you have the value "No" as the actual value of some of these features. If I'm following correctly, the actual value should be "1" so that it is a valid domain code value. What you may have to do is turn off the attribute table option for 'Show domain and subtype descriptions'. In the attribute table, select all features that have the value 'No'. Right-click on the Site_Accessible field in the attribute table and click Calculate Field. Now you can 'force' those values to be "1" through the Calculate Field operation. Ensure the option to 'Use the selected records' looks correct and that you are applying the value to the correct field. --- Another option is to temporarily remove the domain applied to that field you're having trouble with. That will make it easier to find and update 'actual' values that do not match the code value(s) you need to assign. After editing all features to have the correct code values, then you could re-assign the domain to that field. Just a warning that when using a field with domains -- if you use Calculate Field, you must use the code value when applying values with Calculate Field -- if you try to apply a description value with Calculate Field, it does not 'check' if this matches a code value in the domain to assign the code value instead. Calculate Field is more of a 'brute force' edit method. In comparison, the attribute table and attribute pane will show you the drop-down pick list of domain code or description values to choose from and will not let you manually enter a value, even if you wanted to. This is a big problem in my opinion with ArcGIS Pro and domains, maybe it's a bug: if you have a domain description value as the 'actual' value in a feature with a domain, the attribute pane may display it as the matching code value, even though it literally isn't. It's super confusing.
... View more
09-17-2025
09:57 AM
|
1
|
4
|
510
|
|
POST
|
I think you accidentally pasted the Subtype screenshot twice -- can you paste the domain menu screenshot showing the domain code/values you are having issues with?
... View more
09-17-2025
09:52 AM
|
0
|
0
|
1185
|
|
POST
|
Can you say more about this - I'm not sure what you mean: I see some issues when you change field in Unque Values and I see duplicate here.
... View more
09-17-2025
09:46 AM
|
0
|
1
|
1188
|
|
POST
|
I find when diagnosing the warnings like you're seeing where domain coded value is not being recognized in a selected feature: For that layer in your map, if you open the attribute table, there is an option to specifically show domain CODE values instead of DESCRIPTION values. This also changes the behavior of what you see in the attribute pane (but not pop-ups, I believe; you have to change that field value display behavior separately by using an arcade expression to show the domain code value rather than description). This at least helps you see what the 'actual' value of that field is. Changing domain description values in the domain menu should automatically reflect the new description value in your attribute table/attribute pane, unless ArcGIS Pro is being glitchy you may want to close and reopen the project. However, if you change any domain code values, you have to manually update features that need to have that new code value applied.
... View more
09-17-2025
08:02 AM
|
0
|
0
|
1198
|
|
IDEA
|
Update: https://support.esri.com/en-us/knowledge-base/how-to-configure-smtp-servers-in-arcgis-portal-for-test-000033359 I added a test smtp email account to add to my Portal (11.1 in my case) to see what may change. The behavior DOES change in at least 1 way. Although creation of a new account still requires you to enter a password, when performing the password reset step I mentioned above, as the Admin, you no longer see the popup with temporary password information when resetting a user password. Instead, the user is directly sent a boilerplate email with login instructions with the temporary password: I searched around in the Portal Settings but I don't see where this boilerplate email can be customized. In my case, I'm not sure that this is good enough since my users sometimes are being onboarded to our org and have no idea what GIS is and maybe have never even used web maps much. I try to put in some extra information in my emails to new users to give more context to why they are receiving this and what this account is to be used for. For example, we use Portal user store as our single sign-on for Cityworks. I add important context that this account is what is used for Cityworks login, or other secured GIS resources, etc. I often customize the boilerplate email a little bit if I know the user has particular use cases. It appears an idea for customized emails for AGOL has been open for many years and it doesn't seem to have any official response. So I assume Portal is in the same boat. https://community.esri.com/t5/arcgis-online-ideas/customizing-arcgis-online-administrative-and/idi-p/1029626/page/2#comments
... View more
09-15-2025
06:01 AM
|
0
|
0
|
766
|
|
IDEA
|
The standard procedure for me is to create the account, put in a junk password. Then in Portal members menu you can 'reset password' for that user and it provides a randomized 8-character temporary password. I then send a boilerplate email to the user providing a link to the Portal login and their username and temporary password to login for the first time. Using this method, they are forced to create their own unique password (and security question). --- THAT SAID, I completely agree that Portal should make this process basically native so that as an admin you don't have to go through this 'external' hoop of sending an email manually to a user, which is a big pain if you are adding a lot of users at once. Portal ought to be able to send an invite via email with a link to create a unique password for their account, similar to AGOL. I am not sure if the options exist/change if you add an Email configuration in Portal > Settings > Security > Email settings. I don't have that set up in my configuration currently but maybe someone else can confirm if this changes anything when email account is setup with Portal for notifications.
... View more
09-15-2025
05:40 AM
|
0
|
0
|
773
|
|
POST
|
Just curious: for the publisher using ArcGIS Pro, are they using the web adaptor url for signing into your Portal, or the fully qualified machine name:port? And just to confirm, is your Server federated with Portal?
... View more
09-12-2025
05:50 AM
|
0
|
0
|
580
|
|
POST
|
For what it's worth, if you are an admin of the Portal/AGOL organization that you are signed into Pro with, you could potentially change the org's 'default' basemap to a projection that you all primarily use. In my case it's NC State Plane. I created a custom vector tile basemap using that projection and set it as my Portal default basemap.
... View more
09-11-2025
07:02 AM
|
0
|
0
|
661
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-28-2026 08:15 PM | |
| 1 | 03-08-2026 12:16 PM | |
| 1 | 07-22-2025 07:31 AM | |
| 1 | 12-02-2025 03:04 PM | |
| 1 | 11-19-2025 05:45 AM |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|