Remove Addin from user instead of deleting .esriAddinx

[Anonymous User]

I have an Addin that is used across the organization (50+ people). I used the shared folder because:

Designating a well-known folder on a network drive is a convenient way for many people in a workplace to use the same add-ins.

However, if one person decides to delete the Addin from their Pro using the 'Delete this Add-in' button, it deletes the the underlying .esriAddinx file, as indicated in the Managing Add-ins documentation.

If you use the Add-In Manager to delete an add-in that is loaded from a well-known folder on a network drive, the .esriAddInX file is permanently deleted, just as it would be if you used Windows Explorer to delete the file from its location on disk.

There is nothing stopping curious users from deleting the esriAddinx file. This is a huge problem because the Addin is now broken for everyone else and for future users until the esriAddinx file is restored. The 'Delete this Add-in' should just remove it from the users Pro addin list and not delete the underlying .esriAddinx file.

[Bud]

Could you ask your network administrator to change your users’ folder privileges from read/write/delete to read-only? (for that specific folder)

[AndrewQuee]

Sure, and we have.  It still doesn't address the issue of what happens if someone who does have permission does a whoopsie, or if the folder permissions are changed for some reason beyond our control (this has happened to us in the past).  We have also had users arbitrarily added to our domain group without our permission or consultation...

To me the analogy is having two D's on your car gear select.  One is Drive and the other is Destroy.  As as long as you use the first, it's fine.  Choosing the second one instantly destroys the transmission without warning (perhaps as a security procedure to stop car theft).  Adding protective guards around accidentally using the other  D-gear seems counterproductive to... not having it at all.  Which is why it does not exist outside a Mad Max movie. 

I just don't understand the design of this feature, especially when Pro is touted as an enterprise level tool for multiuser-GIS organisations.

To further explain our position, we use addin customisations to deliver business-critical functionality and productivity tools to ~60 users, while the tools are available to the entire organisation (~1000 staff).  While the tools are currently protected as Bud suggested, the default behaviour of one person detonating the custom tools for everyone seems... unwise.

[Anonymous User]

Thanks to everyone that gave a thumb and their thoughts to this. It would be a very useful feature to be able to turn addins off and on without having to delete them, uninstall them, or remove the folder they are in and then add them, install them, or add folder again when needed. As a developer, I wouldn’t knowingly/expectantly put my user/consumer into a situation where they need to manage folder permissions as a precaution against a small (relatively speaking) function of my software.

Along with the on/off switches, it would be nice to get a separation between the Pro projects used for development, and normal use projects. The development addins stick with every project until the dev folder is removed… It should be a temporary instance of Pro that lives as long as the visual studio process runs it, and only the finished release version addins be in the ‘normal use’ Pro projects. Bugs me when I open a project for other work and I see the addins that I am still developing. Hope that makes sense and probably another idea.

Thanks for the support in getting this idea traction and hopefully fixed.

[KoryKramer]

Hi all,

I just talked through this with a colleague and I'd like to get some feedback on the following. The Make administrative settings part of the add-in documentation discusses how to distribute add-ins in the manner that you're referring to.

If I only set up a well known folder from a shared network location (my understanding from the original idea and ensuing discussion is this is how you're all setting up your add-ins):

Then we get the behavior described; i.e. the add-in is recognized under "My Add-Ins" and the user has the ability to delete it.

However, if I follow the instructions referenced above to make the add-in available through the admin workflow, it is recognized under "Shared Add-Ins" and the user is not able to delete it. 

Hopefully this will help many if not all of you. Does this method work for your organizations? If not, can you let us know why not?

Thank you!

[Anonymous User]

Thanks @KoryKramer for the follow up.

The admin method- Every pc that will load these addins will need to have this registry edited? I don't think this is a viable solution for several reasons.

1. We'd have to track this to ensure that one doesn't slip through a crack; and all it takes is one. PC rebuilds, new installs, personnel moving, does this key persist across version updates, or would it need to be set again, (like how the conda environments used to be).  ... It's not making the installation and management of the software product easier.

2. Lets say the addin is mysteriously deleted.  That means either one pc isn't keyed, or it was deleted from the folder- There is no way we can tell.  I am now spending hours++ checking every pc for this key and the damage is already done.  As much time and effort we put into keying every pc, it didn't prevent it from being deleted but still required more time and management.

3. Changing the folder permissions seems like a more stable (one point of contact) solution since it is done once on the folder, and not on every pc that is running Pro addins. But it is still modifying the system in response to a bad functionality of a program...

4. Using the same folder permissions vs. every pc point of failure- esri can solve this issue for every single one of their users by changing the functionality of that button to just remove it from the user configuration and not delete it from disk. They can solve this issue without their users needing to maintain additional folder permissions or per pc registry edits.

5. Why is the person 'deleting' the addin from their Pro project in the first place?  To remove it from their Pro configuration. Why then does it delete the addinx for everyone else? Developers (at least myself) are (probably) more likely to delete the addinx and all of its accompanying dlls/ toolboxes, etc.,. through windows explorer.   If that button was named 'Remove', and it simply removed the addin from the user, its purpose would be achieved.

6. Delete only deletes the addinx and nothing (dlls, toolboxes, stuff) else. We (developers) don't use Pro to delete these files if we are replacing them or moving their location- we use windows explorer so I'd venture to say that the 'delete' is useless for us in that regard.

Edit to add to 6: This is like having a 'remove' button for shapefiles that achieves the task by deleting the .shp file, leaving the .dbf, .shx, .xml, .prj, .cpg, .sbn behind. 

That's all I got time for today- Hopefully others will include their perspective.

[KoryKramer]

Great additional details/context, @Anonymous User Thank you.

[DaveFullerton]

I have to say that the idea of the user deleting the source file is so very counter-intuitive that it just should not be done.  First of all, the users certainly won't have any reason to want to do that.  They don't understand it in the first place.  Second, I think that unless you put big exclamation points in the documentation, many developers might not actually understand that this is what is going to happen.  We are smart people, but it is hard to ingest something that doesn't make sense, doesn't seem to have a purpose, and is unprecedented.  I think the question here should be, "Why is it designed this way?"  If you could tell us why it might be useful to us, then we might be able to give you our full perspective on the issue.  As it is, yes, we are able to use the registry setting, and we prefer to use the registry setting for many of our in-house add-ins that we want all users to have installed.  But we would still like to be able to allow the users to choose to add and remove other add-ins as they see fit by adding or removing a path to a shared location in the Add-in Manager.  We don't have a lot of people in our organization that have admin rights anymore, so doing everything through the registry is not ideal.  And having users each have their own copy of the add-in file (double-click install) is not going to be good when it comes to migrating to a new major release.  There we will see breaking changes, so we want to have a centralized repository of all add-ins in order to see what needs to be fixed before the upgrade.

[AndrewQuee]

Thanks @KoryKramer for investigation and clarification of how it should work.  I did not know you could configure it as an admin add-in.  I confirm to you Kory we are doing it the former way as part of user configuration.

Great comments all round.  Our ICT is not okay with us registry hacking (especially not for clients) so I don't think this will work for us.  We do deploy with the awesomely acronymed MSSCCM-AC (Microsoft System Center Configuration Manager Application Catalog) so it possible that a .reg could be queued into an installation script.  Not sure if that has changed now Pro no longer uses .msi and just has an .exe. 

This still has all the disadvantages @Anonymous User eloquently detailed.  In addition we have raised similar questions with ICT before and they said it was extremely difficult to know where to put the registry node/keys due to a mix of hardware and software (mobile/desktop/virtual, different OS', etc) requiring excess scripting and support on their end.  The documented registry edit looks stable to me though.

[Anonymous User]

I think we need the ability to disable the 'global' install of addins.  Pro is largely per project, (eg, connections, folders, servers, etc) but addins are not.  @SimonSchütte_ct has a great idea being able to turn them off and on depending on the needs.  The issue is we have a server that shared between several departments.  There is one install of Pro on that server. If there is an addin used for syncing public works data to their third party software, our Health department's projects by default load that addin. They could see the login info for the third party software so this is also a security issue. 

[andysp]

Lots of good thoughts on this thread; thank you for thinking through this design. @KoryKramer - the "Make administrative settings" method falls short for us as well, for many of the same reasons @Anonymous User outlines (not the least of which is added admin overhead). In addition, add-ins loaded via HKEY_LOCAL_MACHINE are "Shared Add-Ins" and can be protected, but these apply across the machine - and different users sometimes prefer different combinations of add-ins. Registry folders can be specified in HKEY_LOCAL_USER, but as the documentation states, "This is equivalent to adding additional folders via the Add-In Manager Options in ArcGIS Pro."

Also- love JeffK's line of thinking about the lifespan of development vs production add-ins.