WIHU Suggestion

[kalavera]

I have already asked once for this feature :

- Add the possibility to see during runtime the user.operations written on install.ini and be able to disable then (for example unchecking a checkbox next to each entry).

- Also the possibility to add new user operations entries via the GUI.

i'm using this install.ini right now:

[settings]
SkipSoftware=1
NoRestartChange=1
RestartWait=3

[users.operation]
disable.0=Administrator
disable.1=Guest
delete.0=ASPNET

Thanks and keep the good work.

[BenjaminKalytta]

Yes, I'll add this as I said. But Im currently working on User Account Creation Interface which will be changed to be more relieable.

Benjamin

[BenjaminKalytta]

I decided not to add this to UI because once I also said that this should be treated as temporary solution. It would be much nicer if this could be done with existing interface. Im currently working on it.

What do you think about it? However, users operation would still be possible.

Benjamin

[kalavera]

If you can implement the same feature (disable, rename and delete) via the current interface all ok for me.

One thing i think is strange is the being able to do the same operation on 2 different places (for example in [user] you can disable a user, and you can do the same in [users.operations]). maybe a unified way to change user properties would be the best.

My first suggestion was the now forgot feature to edit the current system users ... this way would be the best way to change the users. For example we can have in install.ini some defaults (like disabling Admin or deleting ASPNET) but then in runtime we could change this default behaviours.

Maybe getting back this old feature but with changes ... maybe not full user editing capabilities just simples user operations. Also not showing by default the users, or the possibility to only show some certain users in the list (for example hide the SUPPORT account that newbies don't know that even exists).

Another thing is (i already suggested this one sometime ago), be able to just rename the Administrator account to something else instead of creating a new user and then disable the admin. This only have may has problem when runned from runonce (with the Admin already logged on) but i'm not sure.

But at least don't let something to occur: Let the user choose user current logged on account (Administrator when runned after an installation cd) and if there is a user operation to disable or delete Administrator disable this operations.

Thanks, but as i always say ... the creator has always the last word. We, users, just make suggestions, sometimes personal tastes.

Keep the good work!

[BenjaminKalytta]

If you can implement the same feature (disable, rename and delete) via the current interface all ok for me.

Yes everything will be possible, I'll describe in detail later how to do this.

One thing i think is strange is the being able to do the same operation on 2 different places (for example in [user] you can disable a user, and you can do the same in [users.operations]). maybe a unified way to change user properties would be the best.

No, at this time it isn't possible to delete a user in [users] section. This is currently only possible in [users.operation] section. This will be changed in version 2.1.8.0.

I'll keep [user.operations] until at least newt main release.

Another thing is (i already suggested this one sometime ago), be able to just rename the Administrator account to something else instead of creating a new user and then disable the admin. This only have may has problem when runned from runonce (with the Admin already logged on) but i'm not sure.

This is possible at the moment. You have to combine /UseCurrent and /Admin= switch. In new version 2.1.8.0 you have to select "[x] Use currently logged on user" and create a new account "Administrator" in second dialog.

But at least don't let something to occur: Let the user choose user current logged on account (Administrator when runned after an installation cd) and if there is a user operation to disable or delete Administrator disable this operations.

Why not? User account will disabled then on next logon only.

Benjamin

[BenjaminKalytta]

So I released version 2.1.8.0. Please take a look at the changelog for details.

Following image will show how to "undelete" a previous deleted user within WIHU user interface which was specified as deleted in install.ini.

To modify an existing account from within WIHU UI please follow these steps:

1. Create a new account, specify existing name

2. Press "OK". This new user will then be initialized by current account settings like user comment, user full name, user profile etc.

3. ... now this user is ready to edit.

Benjamin

[kalavera]

First of all good work.

Some things:

- First of all a very minor cosmetic spell. In the Edit user account dialog (you can see it in the picture above) unchek -> uncheck

- Another minor thing would be hide the properties command from context menu when isn't unavailable instead of showing the dialog with the message.

- I noticed that operations in the [users.operations] aren't showed in the users list ... but i think this is planned.

- There isn't the possibility when creating the user accounts just to edit them, to get a list of the current accounts in the system instead of just typing it? Maybe with a combobox would be very nice.

- About this:

Let the user choose user current logged on account (Administrator when runned after an installation cd) and if there is a user operation to disable or delete Administrator disable this operations.

The problem is when you don't create a new user account ... then you will be stuck on entering windows! Maybe a check in this case to remember the user for the problem and don't let it continue. (I say this because i friend of mine did it! )

- Renaming Administrator : I know it can be done via switches ... but i say doing it via GUI. This feature would be nice for people that don't want to create new users, but just want 1 Admin account, but renamed, without having to go and create a new, and disable the old one.

Once again, thanks.

And as i always say ... keep the VERY good work

[BenjaminKalytta]

- First of all a very minor cosmetic spell. In the Edit user account dialog (you can see it in the picture above) unchek -> uncheck

Thx.

- Another minor thing would be hide the properties command from context menu when isn't unavailable instead of showing the dialog with the message.

It's better this way because the dialog contains a hint for the user what to do etc.

- There isn't the possibility when creating the user accounts just to edit them, to get a list of the current accounts in the system instead of just typing it? Maybe with a combobox would be very nice.

Yes this is coming soon.

- I noticed that operations in the [users.operations] aren't showed in the users list ... but i think this is planned.

No, as I said each operation can be done by ordinary user account now. There is no need also to show this ... btw. in next main release I'll remove this user.operations because it's senseless to add 2 features with the same operations.

- Renaming Administrator : I know it can be done via switches ... but i say doing it via GUI. This feature would be nice for people that don't want to create new users, but just want 1 Admin account, but renamed, without having to go and create a new, and disable the old one.

No, there will be no extra interface to rename administrator only. This can be done with existing interface.

The problem is when you don't create a new user account ... then you will be stuck on entering windows ...

Sorry but I don't understand what you want to say.

benjamin

[booster]

- Renaming Administrator : I know it can be done via switches ... but i say doing it via GUI. This feature would be nice for people that don't want to create new users, but just want 1 Admin account, but renamed, without having to go and create a new, and disable the old one.

No, there will be no extra interface to rename administrator only. This can be done with existing interface.

Can't seem to find out how to rename the admin user with the GUI ?

Can anyone give a quick point in the right direction

[BenjaminKalytta]

@booster: As I wrote:

1. Create a new account, specify existing name

2. Press "OK". This new user will then be initialized by current account settings like user comment, user full name, user profile etc.

3. ... now this user is ready to edit.

After 3. you may edit it's name -> rename.

Benjamin

[booster]

thx

I was logged in as "Administrator" and just used "Use currently logged on user" so it was not shown in the list.

[kalavera]

Thks for the reply.

About the thing you don't understand ... i will try to explain better:

- You choose "User currently logged on user" (Administrator)

- You have in [users] or in [users.operations] the instruction to disable Administrator.

- And you don't create a new user account.

- Then there will be a problem! Because there isn't any available user account to enter in windows.

My suggestion is to make a simple check, and see if there is only one account and is going to be disabled or deleted then don't let the user continue.

I hope i was able to express my ideia.

Edit:

This is my current install.ini

[settings]
SkipSoftware=1
NoRestartChange=1
RestartWait=3

[Users]
; Disable Administrator account
user.0=Administrator
status.0=0x002
Group.0=1
password.0=1A6178031B607F041A617C071B6073081A61700B1B60770C1A61740F1B601B60D0
crypted.0=32

; Disable Guest account
user.1=Guest
status.1=0x002
Group.1=0
password.1=1A6178031B607F041A617C071B6073081A61700B1B60770C1A61740F1B601B60D0
crypted.1=32

; Delete ASPNET account
user.2=ASPNET
deleted.2=1
password.2=*

It is all correct for my proposal? Thanks

[BenjaminKalytta]

@kalavera: Yes I understand your explanation, but I wont prevent this because the user who is using WIHU is responsible for bewaring not to enter invalid data.

Your install.ini is OK.

Edit: Ok I'll show a hint message.

Benjamin

Edited September 4, 2004 by BenjaminKalytta

[presende]

First of all: Congratulations Benjamin, what a great program!

I would like to make some suggestions for future releases:

1. New items attributes: Locked = 1|0 and Disabled = 1|0

------------------------------------------------------------------

Locked: Don't allow changing the Selected value.

Disabled: Grayed + Locked.

2. Adjust a little the meaning of comparison operators

--------------------------------------------------------------

I have some dificulties to completly understand the existing rules.

My suggestion:

 ?                                True if file or registry key or value exist.
 ?!                                True if file or registry key or value doesn't exist.
 ?=                                True if file exist but as no version information or
                                   if registry key (registry values don't apply) exist but is empty (has no values).
 ?= <file version>                 True if file exist and has version equal to.
 ?= <dec|hex number> or <string>   True if registry value has data equal to.
?!= <file version>                 True if file exist and has version different from.
?!= <dec|hex number> or <string>   True if registry value has data different from.
 ?> <file version>                 True if file have version info greater than <file version>.
 ?< <file version>                 True if file have version info lesser than <file version>.
?>= <file version>                 True if file have version info greater or equal to <file version>.
?<= <file version>                 True if file have version info lesser or equal to <file version>.

(I think that ?!<= and ?!>= have no need to be used because there are alternatives)

3. New attribute: CaseSensitive = 1|0

-------------------------------------------

Just for helping when comparing strings.

4. Explicit [Root] section for setting default values

-----------------------------------------------------

This section has a fixed name [Root] and could have these attributes:

[Root]
   Group = 1|0
   Selected = 1|0
   Collapsed = 1|0
   Locked = 1|0
   Disabled = 1|0
   Hidden = 1|0

Some of them, apparently have no use or just don't make sense, but I think that their use is for setting defaults that apply to the hierarchy. The defaults could be after changed explicitly by sub-items/trees/branches.

5. Adjusting the name for file and registry commands

-------------------------------------------------------------

file -> filever

Making room for future

filename

filedate

filesize

key -> regkey and regvalue

6. Evaluating in conjunction file and registry key/values

----------------------------------------------------------------

comparison.x = AND|OR
regkey.x = <path\registry key name>?<comparison operators)><string or number>
regvalue.x = <path\registry value name>?<comparison operators><string or number>
filever.x = <path\file name>?<comparison operators><file version>

7. Sublevels in comparisons

--------------------------------

Example:

comparison.x = AND|OR
comparison.x.y1 = AND|OR
regkey.x = <path\regkey>?<comparison operators)><string or number>
regvalue.x = <path\registry value name>?<comparison operators><string or number>
comparison.x.y2 = AND|OR
regvalue.x = <path\registry value name>?<comparison operators><string or number>
filever.x = <path\file name>?<comparison operators><file version>
comparison.x.y1.z1 = AND|OR
regkey.x = <path\regkey>?<comparison operators)><string or number>
regvalue.x = <path\registry value name>?<comparison operators><string or number>
comparison.x.y1.z2 = AND|OR
regvalue.x = <path\registry value name>?<comparison operators><string or number>
filever.x = <path\file name>?<comparison operators><file version>

7. Opportunity to take different actions (from initial default attributes) from global comparison result

--------------------------------------------------------------------------------------------------------

Example:

description.x = Description x 
command.x = cmd.exe /c @echo Command x
;Default attribute values
Selected.x = 0
Collapsed.x = 0
Locked.x = 0
Disabled.x = 0
Hidden.x = 0

comparison.x = AND|OR
regkey.x = <path\registry key name>?<comparison operators)><string or number>
regvalue.x = <path\registry value name>?<comparison operators><string or number>
filever.x = <path\file name>?<comparison operators><file version>

ifresult.x = 1 (attributes to change if comparison result is true)
Selected.x = 1
Collapsed.x = 1
Locked.x = 1
Disabled.x = 1
Hidden.x = 1
;If comparison result is false the default attribute values are not changed.
;Also this is for example, it does not make sense using all attributes together.

Thanks for your wonderful work and keep going!

Paulo

[my2001]

Wow! Yeah, some things sound good, indeed.