Add a trusted toolbox list or a don't ask again button for 3rd party code warning when refreshing a Toolbox.

[GISDepartmentMFM]

A new feture was recently added to ArcGIS Pro so that when a python toolbox is refreshed it will popup with the Warning: "

Opening a Python toolbox runs third-party code. Confirm you trust the source before proceeding.

(file Path)

Allow this toolbox code to run?

"

This warning gets really annoying when developing python toolboxes and it would be nice if there was a way to permanently mark it as a trusted 3rd party for the project with a "do not ask again" button or be able to set a trusted directory that has all the users toolboxes as white listed and  to not show the warning again.

[DrewFlater]

We are treating the Security warning on Refresh as a defect at this time, to be addressed in the near term. 

If you only use Python Toolboxes from yourself/your organization which are all trusted, you could consider setting BlockNonSystemPythonToolbox to No.

https://pro.arcgis.com/en/pro-app/latest/get-started/geoprocessing-settings.htm#ESRI_SECTION1_88A083... 

[philnagel]

Any more info on this? I reached out to support to get the defect attached to our org and was told it was not in the system. 

[HannesZiegler]

Hey @philnagel, sorry for the confusion, since this came in by a different route (identified by way of the ideas post), there's no support ticket for it. I confirmed there is an internal issue tracking this bug for inclusion in the current release cycle (ArcGIS Pro 3.6). The reason this idea hasn't been updated publicly with an "in product plan" status change is because we are treating the defect separate from the idea you posted, which was to add an option to whitelist toolboxes/directories. Status for the idea is what is tracked here.

Feel free to ping us again here if you need another update on the (separate) defect.

[philnagel]

@DrewFlater @HannesZiegler  We have a lot of custom PYT toolboxes that are included in all of our APRX templates and we have noticed some significantly increased initial loading times of the first toolbox in each Pro instance, as compared to previous versions. Wondering if something related to this third-party code detection or something else might have something to do with that? It seems that all of these toolboxes are fully initialized now when the first toolbox is accessed, which I don't believe was the case before.

[HannesZiegler]

@philnagel PYT toolboxes are cached in memory when accessed and reloaded when a change is detected. The third-party code permission check will be triggered each time the PYT is edited (change is detected). Executable code at base level or the root (static portion) of a Python class can cause it to run during catalog interactions, which may contribute to longer loading times. Best practice is to encapsulate such code within method/function blocks to avoid premature execution.

[AlfredBaldenweck]

Bumping this thread to report some serious performance issues as a result of this setting.

I had a user whose entire Pro session would freeze when trying to create a shapefile from the catalog (right-click->new->Shapefile). The Geoprocessing Pane would open, everything would grey out, and the pane would never end up properly opening the Create Feature Class tool. We'd wait like 10 minutes before nuking Pro and starting over.

Did a lot of experimenting and determined it was a combination of two things:

1. Not having opened the Geoprocessing Pane in that session already
2. Having a python toolbox in the project's connections.

Opening the GP pane took a minute, but it did actually let things work. Removing the PYT removed the problem entirely; it opened to the correct tool in seconds.

I attempted to replicate in a fresh, unrelated project. I never got anything as bad as what this user was getting, but there was a minutes-long delay in opening the tool.

In conclusion

1) I think that having the option to permanently trust a location or file should be available, and I'm glad to see that it's marked as Under Consideration.

and 

2) I think that if this sort of check is going to continue to exist, there needs to be a serious look at ensuring it doesn't cause performance issues. The only way to fix this was to force-quit Pro with Task Manager. This is not good. It's one thing to have some lag when you're actually using the toolbox, but it should not be causing problems when it isn't even open.

This is a problem along the same lines as Reduce the amount of license checking, where every action caused a license check, even to unrelated licenses, or how (can't find a handy Esri Community link for this) each broken link in your project causes a performance drop because Pro can't stop checking to see if they're still broken (again, checking every time you do something. I had a guy whose [admittedly enormous number] broken links caused opening the geoprocessing pane to take more than 30 seconds. Removing the broken links made it instantaneous). There's a general pattern of duplicating checks instead of just doing it once (or idk, like every 3 hours would be acceptable if you really have to keep checking) and letting the user move on with their day.

And again, it should not be a problem until you actually try to do the thing. You should not be worrying about any toolbox until the you open it. Why am I getting this check for a toolbox I use once each week and today is not that day? Why I am I getting the check for the toolbox when I open it from catalog and then again when I run it from the GP History pane in the same session? Wasn't once enough? Why am I getting this check for a toolbox I confirmed I was cool with yesterday? It hasn't been edited and I haven't changed my mind.

I'm really hoping this gets resolved in a near release.