Addin Auto Update choices codified in addin.def

[nathan-clark]

What inspired this wish list request? With JMP19 on the scene, I noticed an auto update feature for addins where JMP will look for udpates to files from an 'install folder'. The implementation was a bit "clunky" and ends up breaking a bunch of infrastructure we already had built.

What is the improvement you would like to see? Rather than living in the Views > Addins settings, these choices should be codified in the addin.def file all addins need. It will make it easier for those with existing infrastructures to manage as well as easier to implement part of JMPs cool features iteratively.

Why is this idea important? I want to take this feature to the next level. It's a super great idea, but its current implementation can easily cause issues for others. In my current infrastructure, updates are checked for against a master list to know when new versions are released. JMP's feature could deprecate the need for some of this, but it needs more finesse in how it's laid out. Some examples:

1. Addin installed from correct location, all is well... later on user can't access location and needs the update. I pass along the jmpaddin file to them so they can keep on going. They drag it into JMP ... now it's possible the install source is now the downloads folder and they wouldn't get notified of updates because of that change ... hard coding the correct source into the def file would allow this to work regardless.

2. Testing addins. Similar to #1 if you have a folder where your tests are located, installing a test file would change your install location to the test location and they wouldnt get notified when a new prod release happens. And depending on how files are named they may or may not be notified of new test versions ... because test versions are often 'handed' off, they include teh version in the filename... so an exact filename match isn't possible for the update checks.

In both of these examples, there are aspects of what JMP has done that could be useful, but the deployment team needs more control in how their addins shall be marked for update. There are probably more example, but I think this is enough to get the ball rolling for the update 'stuff' to be part of the addin.def file with one or more variables there.

Thanks!

[nathan-clark]

Agreed! This is part of why I want it codifiable via the addin.def.

The biggest thing I am not a fan of is the install source changing... likee your sharepoint @hogi , if the install a beta version that source may be altered to the beta location... so they woudnl't be notified if a new PROD was created.

Little things like that potentially break existing infrastructure/pathways :) Thankfully I don't htink the 'lift' is super hard to support muptiple avenues.

[hardner]

If you downloaded the file from the Sharepoint and then opened it from your "Downloads" the auto-update will do nothing on the assumption it's making that the install location? The customer I was working with was, I believe, hoping this would allow specifying a remote location to check for an update (their corporate server or sharepoint or whatever) - regardless of how the user had opened the file, this official location would have been specified, such as in addin.def as the place to seek updates.  And there would not be errors if that location was inaccessible.

[nathan-clark]

@hardner you can sync your Sharpoint so the folder can show up in your file explorer as though it's local. Within a sharepoint location there is often a "Sync" button which brings it down as a local synced folder accessible as any otehr folder on yoru drive.

If they do download the file directly, you are correct that can also 'break' the intended pathway.

I can't say 100% this is common company to company, but at least that's how ours works ... there may also be a 'create onedrive shortcut' button also. Does someething similar, but I try not to use this button (soap box for a different day).

[hardner]

Understood.  I use Sync but also belong to sharepoints that don't allow me to Sync.  My first thought would be to download something like this just so that I "have" the file.  Regardless, mainly was noting this logic only works usefully if users open the .jmpaddin directly from the official location where updates will appear and it's not clear to me you can enforce that they do that as vs. download, email the file around, or whatever.  

[nathan-clark]

Yup, that makes sense. I think what JMP is trying for makes a lot of sense and can streamline lots of headaches ... My biggest drive for change was their implementation breaks mine :) But with the right controls I may be able to deprecate some of my infrastructure to rely on JMPs implementation!

[hogi]

how about: AddinLoad.jsl?

- overwrite Installation fie to Company Standard
- if Test-Dir: show a warning that a test version is installed - suggest the user to install the official release from the official source
- if InstallationDir=Download -> disable update

We just have to find out where the information is saved  - and then read, reacht and change it.

[nathan-clark]

addinload files can be finicky depending on how you utilize them and the order JMP installs things. i built my stuff based on libraries that are included when I need them ... but i've used addinload in the past. My system is rock solid otherwise - until JMP gave options back to the user :D 

Bottom line for me, I'll use JMPs stuff if it's better than mine, but I odn't want to be forced into JMPs stuff.

[hogi]

ah, here it is:

Open(
	"$USER_APPDATA_ALL/addinRegistryV2.xml",
	XML Settings(
		Stack( 0 ),
		Row( "/AddinReg/Addins/Addin/@id" ),
		Col(
			"/AddinReg/Addins/Addin/@id",
			Column Name( "Addin.id" ),
			Fill( "Use Once" ),
			Type( "Character" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@timeStamp",
			Column Name( "Addin.timeStamp" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@installSource",
			Column Name( "Addin.installSource" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@installSourceTimeStamp",
			Column Name( "Addin.installSourceTimeStamp" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@autoUpdate",
			Column Name( "Addin.autoUpdate" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@updatePrompt",
			Column Name( "Addin.updatePrompt" ),
			Fill( "Use Once" ),
			Type( "Character" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		)
	),
	XML Wizard( 0 )
);

Just remove the autoUpdate tag and your colleagues have to rely on your rock solid implementation.

Maybe install an UpdateCheck AddIn which checks the settings, adjusts them and complains if the settings are wrong.

[nathan-clark]

Oh, interesting @hogi! That definitely seems like a workaround i should play with :) JMP support also gave me some JSL thatt I could use to turn off the setting when updates happen, that I need to play with also.

Names Default To Here( 1 );
/* Installing Add-In:
Open( Add-In to open,
    <Check For Updates( "never" | "startup" | "always")>, // "always" will check for updates at startup and while jmp is running
    <Update Prompt(0|1)>) // whether or not the add-in will silently update or prompt first */
Open(
    \\NetworkLocation\addins\test.jmpaddin,
    Check For Updates( "never" ),
    Update Prompt( 0 )
);

[hogi]

ah, wonderful!

Ideal to set up a batch-script to update the update:
run all the AddIn Installers and adjust the settings.