---- Reported by mason@kohaaloha.com 2008-06-11 07:38:58 ----

The idea of this feature is to allow userid and password be populated automatically from other fields, when adding a new user.

this has a few other benefits

1) in combination with user-permissions locks userid and password fields from manually being changed
2) populates password field with randomly generated passwords

the feature currently uses the jscript onkeyup() function to update the destination fields character by character - when the source field is changed



---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:41:22 ----

Created an attachment
AutoAddUserid syspref example





---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:42:03 ----

Created an attachment
AutoAddPassword syspref example





---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:48:12 ----

Created an attachment
example of 'email' src field populating 'userid' field, and 'password' field populated with random value





---- Additional Comments From mason@kohaaloha.com 2008-06-11 20:03:17 ----

Hi Joe

On 2008/06/12, at 7:17 AM, Joe Atzberger wrote:

Mason --

There are a handful of problems I see with this patch.
Uses EXPR in a way guaranteed to create multiple warnings unless both of these new features are ON.
Good call, i didn't consider the log warnings here,  i will fix this
Uses EXPR at all.
Hmm, i dont understand your point here, is *any* EXPR usage bad, or just unneeded EXPR usage?

I'm sure i *could* rewrite this mod to not use EXPR tags, but the template would be much more confusing than using EXPR tags. 
And i would need to introduce 8-ish? new TMPL_VARS to the script if i removed the EXPR tags, is that a better solution??
Or do you know a better way still to achieve this?

Did i use an unneeded EXPR tag, instead of a VAR tag?

Adds meaninglessness (e.g. "home111", "email33") to labels.
Sure, late-night last minute typo there, i will fix this

Changes sort order of branches to be by code instead of the name that actually displays.  I.E., allows apparent disorder in display.

Good spotting, i did seem to miss Ryan's recent branch-sort commit there

 -for my $branch (sort { $branches->{$a}->{branchname} cmp $branches->{$b}->{branchname} } keys %$branches) {                                              
+foreach my $branch (sort keys %$branches) {   


Uses onkeyup instead of something more logical.  (Not every keypress changes value.)
Sorry - my jscript isnt that hot, so i welcome a better way to do this, 
any suggestions for a better jscript function/solution? 

FYI: There are many examples of onkeyup() being used in this fashion, so it seems to be a commonly used/accepted solution?
-> http://www.w3schools.com/jsref/jsref_onkeyup.asp

The whole idea of the proposed CAN_user_nonstaffaccess, as I interpret it, is to block updates to nonstaff accounts unless the permission is granted to the operator.  Is that the intent?  I don't understand the rationale for doing it this way, since the user should probably not be allowed to memberentry at all in that case.  

Is there really a need to allow, for example, CAN_user_staffaccess but NOT CAN_user_nonstaffaccess?

There might be..
But there *is* a need to disallow access to *all* category_types, which was the goal of this additional user-perm.
I realise there are a few ways to achieve this too..

One way would be to change the existing 'staff_access' perm to handle all cat_types, not just staff - (the perm would need to be renamed too)
I think this is the best idea, but some people might not like that the 'staffaccess' user-perm's behavior is changed, 
i dont yet know, so i didnt want to fiddle with it.

So adding a new user-perm was the less invasive initial commit. rather than the best commit

But if people agree, changing the existing staffaccess user-perm to allow/disallow *all* cat-types, and updating its name to reflect the new behavior would be the best solution ( 'editlogins' perhaps?)

Any comments on this last point peoples?

Thanks for checking my patch Joe, You did spot a few things that i overlooked.

Mason




---- Additional Comments From mason@kohaaloha.com 2008-06-13 09:01:41 ----

Created an attachment
Adding a jscript button to generate a new random password, but only if 'staffaccess' user-perm is on





---- Additional Comments From nengard@gmail.com 2009-12-17 00:52:15 ----

I need a clarification about this.  Does this mean that you have to add those preferences to local use and set them the way you're suggesting? or are these system preference supposed to be there for all?



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:48 UTC  ---

This bug was previously known as _bug_ 2237 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2237
Imported an attachment (id=578)
Imported an attachment (id=579)
Imported an attachment (id=580)
Imported an attachment (id=581)

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was mason@kohaaloha.com.
CC member arm@hanover.ca does not have an account here
The original submitter of attachment 578 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 579 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 580 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 581 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.