[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]

kalavera said:

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.

kalavera said:

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.

kalavera said:

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.

kalavera said:

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]

kalavera said:

- 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.

kalavera said:

- 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.

kalavera said:

- 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.

kalavera said:

- 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.

kalavera said:

- 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.

kalavera said:

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]

BenjaminKalytta, on Sep 4 2004, 02:20 AM, said:

kalavera said:

- 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:

Quote

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

This post has been edited by BenjaminKalytta: 04 September 2004 - 10:06 AM

[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.

[BenjaminKalytta]

@presende:
Thx for suggestion, some things sounds really good. But I think I've to make a little development break because I've to learn something for my next study semester which continues in october.
I'll repeat: everyone is welcome to modify my source, I'll provide this on my web site in next days.

Benjamin

[kalavera]

Just a quick note:

- I have tested version 2.1.9.1 and the "hint" didn't appear, i tried on deleting the user logged on or disabling it, both should show a message when leaving the user dialog not letting the user continue or when entering the user dialog (maybe better)

- Only appeared in the installation log a warning about not being able to copy the new profile.

- One minor thing, when you click cancel the messagebox isn't modal, so you can continue clicking in the application, for example cliking various times on the cancel button

Thanks

[BenjaminKalytta]

It's fixed now.

Benjamin

[presende]

I wish you luck with your studies and hope that you can retake programming WIHU soon. Also I see that your recent work has been centered in user settings and its logical to finish it and erradicate small glitches and bugs.
I will use mostly WIHU for hotfixes, updates and feature packs installation for several softwares (Windows, Office,...) and it's important to me that I can check (file versions and registry keys/values checks combined) for previous updates installations, possible language conflicts and instabilities with updates and making harder or even impossible that an update that is not applicable to a system can be installed (Locked & Disabled attributes).

For me, from my last suggestions, these are the most important (in my preference order):

1. New items attributes: Locked = 1|0 and Disabled = 1|0
2. Opportunity to take different actions from global comparison result (changing initial default attributes)
3. Evaluating in conjunction file and registry key/values
4. Adjust a little the meaning of comparison operators

As for modifying your source code, I leaved software development long time ago, and I've no knowleged for that. Sorry I can't help more.

Thanks again,
Paulo

[kalavera]

Sorry to tell you ... but i have tried the newest version and i still don't get the warning when disabling or deleting the currently logged user. It just let's me do it.

But i have found the error ... you are just making the warning when you select a user account in the GUI to disable or delete. You don't do the check from the operations loaded from the install.ini.

Maybe when entering the users list and loading the users you can do that check and giving the option to removing that "bad" entry (maybe a yes or no messagebox to do this automatically).

- One last suggestion ... maybe the cancel button in the finish dialog should be disabled or hidden if you want to force restart.

Many thanks for your time, and good luck for your exams!