Disable Updates

[j_c_hallgren]

The problem is: what's "basic" among so many features XY has?
Also, I don't think Don would take the time to deny access to certain areas and allow it to others, all "admin-defined".

Well, there's a huge difference between allowing users to update the software itself vs allowing them to customize color scheme or what size thumbnails to use, etc! The first makes perfect sense in a controlled corp env but again, I've never heard of any place restricting the second category.

[SkyFrontier]

@Hallgren: of course there is.
I was just thinking on Don's call:

...Any ideas anybody for other things that employees should not be able to do?

Hallgren:

...I've never heard of any place restricting the second category.

Starting with MS group policies and ending with instant messaging/internet access limitations/prohibitions, perhaps...?

[admin]

Since we're talking corporate environments here, I would like to bump this thread again.

http://www.xyplorer.com/xyfc/viewtopic. ... g&start=15

I still believe cascading catalogs would make sense especially in multiuser / multi-department installations.

LOL. Yes, it is still on my list...

[serendipity]

License and Scripts protection also could be considered regarding this matter (I'd *really* not want some of the co-workers having access to the scripts structure!), but perhaps the best idea on this matter is not allowing any changes via GUI (so "Open Config File..." must be grayed, too) except if a master password is inserted to unlock access to Config options, and should be split in: 1) no access to Tools > Config panel, 2) disallowing the save of settings, 3) both.
And by denying access to Config options I mean: they must not even see how the options are set, so the password prompt must show instead when they go to Tools > Config!

I agree with JC, all this is totally unnecessary. Why waste one's time when there are several interesting features in the pipeline? The OP's request was to block "Check for updates" period.

[serendipity]

This is actually going out to about 30 users so if i was to tweak this through an ini file where should i insert DisableCheckUpdates & what should be it's value?

Just curious:
You have already purchased 30 licenses and want to know how to disable updates?
Or
You will purchase 30 licenses if there is a way to disable updates?

[msigurus]

Already bought 30 of them still waiting to find out how to disable the "check for update" Tab.

[admin]

Already bought 30 of them still waiting to find out how to disable the "check for update" Tab.

OK, I was generally planning to make the crowded menus a bit more configurable. I can as well start with this one. Only, would it be enough for you to add a checkbox "Disable Check for Updates" to configuration? The user could easily uncheck it again...

[serendipity]

Already bought 30 of them still waiting to find out how to disable the "check for update" Tab.

Thanks a lot for buying . I hope admin will consider your request. I can see that some organizations have these rules. Thanks also for spreading the word about XY.

[j_c_hallgren]

Already bought 30 of them

just wanted to say THANKS from a devoted fellow user for doing so!

Only, would it be enough for you to add a checkbox "Disable Check for Updates" to configuration? The user could easily uncheck it again...

I would suspect that a INI tweak that is a bit obscure would be more in keeping with OP's desire to keep users away from it...

[admin]

OK, v9.60.0101:

- open xy
- menu file / settings / save all settings
- menu tools / open configuration file...
- in editor:
search key MenusOff
set MenusOff=64
save configuration file
close editor
- menu file / restart without saving

Now menu Help / XYplorer on the Web should be gone.

[nas8e9]

OK, v9.60.0101:

- open xy
- menu file / settings / save all settings
- menu tools / open configuration file...
- in editor:
search key MenusOff
set MenusOff=64
save configuration file
close editor
- menu file / restart without saving

Now menu Help / XYplorer on the Web should be gone.

I wonder whether this would be even more valuable if this setting and restrictions like it, are (also?) in startup.ini rather than the user-modifiable settings .ini. Although the OP does have some users with admin rights, most managed environments don't allow users to write to %ProgramFiles%, thus making it more secure to store this setting in startup.ini (which has to be in in XYplorer's app folder).

[admin]

I wonder whether this would be even more valuable if this setting and restrictions like it, are (also?) in startup.ini rather than the user-modifiable settings .ini. Although the OP does have some users with admin rights, most managed environments don't allow users to write to %ProgramFiles%, thus making it more secure to store this setting in startup.ini (which has to be in in XYplorer's app folder).

This is exactly the thought I woke up with this morning!

PS: I think it would be more practical to put it in a extra file, say config.ini. This file could then easily be dropped into <xypath> by an admin.

[admin]

Ok, here's the new wy to do it (v9.60.0102):

Create a file "config.ini" in the path where XYplorer.exe is located, and put this into the file:

Code: Select all

[Settings]
Hide=64

Done.

Start XYplorer and the "XYplorer on the Web" menu is gone.

[SkyFrontier]

Code: Select all

v9.60.0102 - 2010-10-21 11:13
  +++ Admin Settings: Now you (if you have the rights to do so) can
      place a file "config.ini" in XYplorer's application path where you
      can control the layout and functionality of the application in a
      way that a user without admin rights cannot influence. XYplorer
      will read this file at startup but never write it.
      Currently you can use config.ini to hide a number of menus resp.
      disable the related commands. The numbers in parentheses are the
      values to use in the INI key below:
        Menu Tools | Open Configuration File (32)
        Menu Help | XYplorer On The Web (64)
        Menu Help | Update Registration Details  (128)
        Menu Help | About Box | Clickable URLs  (256)

Despite my usage for this currently is more on the "potential" scenario (under development), I'd like to say thanks for this. The complete disabling/limitation of Config window is a natural step since now we have the "Admin Settings" on discussion, but I see as a great thing users now not being able to accidentally screw the .ini file simply out of curiosity.
So again - thank you very much, Don!

[admin]

More admin settings can and will follow. I agree that this has potential...