Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I just tried to use PluginManager on my office machine (Win7/94 pro unprivileged with a few extra group policies). Download takes place, I'm asked to allow reload. I say yes, and then nothing happens. N++ and the manager dialog remain open and otherwise function normally.
phe Plugin_manager_temp newly created folder has a plugin1 subfolder the downloaded file and a dow9BA9.tmp file.
Our office boxes have a number of security measures enacted by group policy, so there is no overriding them.
It would seem that the plugin contemplates two use cases only: install in %programfiles%, in which case elevation is resquired, and %appdata%, where it is not needed. In the case at hand, we install on a different drive, and Plugin Manager thinks it needs to run as admin, which is prevented.
Perhaps the right thing is to add an option not to run elevated no matter what.
Installling the plugin manually works fine, thanks.
This "third case" is definitely an issue. A known issue, but an issue non-the-less.
I have a plan to fix gpup.exe, so that it starts as the standard user (non-elevated), then attempts to copy the files. If that fails with access denied, then it attempts to start itself again with elevated permissions. Once the file copy is complete, this elevated process then completes, returning to original non-elevated process. The non-elevated process then restarts N++.
This solves the "third case" by checking if files can be copied without elevation, but more importantly means that N++ is restarted with the same level of elevation as it was originally started (ie. start as normal user, after restart from gpup.exe, still normal user, but start as admin, restart from gpup.exe, still elevated).
No idea when this will be, but that's the fix/plan.
Thanks Dave for the reply and future fix. I was thinking that the simplest thing to do /in theory/ is indeed to try without elevating first, and request privileges only if needed.
For the time being, the workaround I found (after inspecting the code) is to temporarily rename doLocalConf.xml so that gpup.exe thinks it will use %appdata% and won't try starting elevated. The workaround works, at the cost of extra file manipulation by user.
Renaming dolocalconf.XML shouldn't have any effect, as that only changes
where the plugin config is stored, not the plugin itself. Gpup needs
elevated permissions to copy the DLL, at least in the standard case. Using
allowAppDataPlugins.XML (I might have the name wrong) will allow PM to
install the plugins themselves to appdata.