User Tools

Site Tools


software:dailydata:libraries:php_user

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
software:dailydata:libraries:php_user [2021/08/25 19:25] rodolicosoftware:dailydata:libraries:php_user [2021/08/25 21:31] rodolico
Line 13: Line 13:
 You can get a copy of this from our subversion repository You can get a copy of this from our subversion repository
 <code bash> <code bash>
-svn co http://svn.dailydata.net/svn/php_users/stable php_users+svn co http://svn.dailydata.net/svn/php_users/tags/stable php_users
 </code> </code>
 My working copy is at My working copy is at
Line 124: Line 124:
                      'hint'     => 'E-Mail Address',                      'hint'     => 'E-Mail Address',
                      // a regex to run it against to verify it is ok                      // a regex to run it against to verify it is ok
-                     'filter'   => '/[-_a-z0-9.]+@[_a-z0-9]\.[a-z0-9]/i',+                     'filter'   => '/^[-_a-z0-9.]+@[_a-z0-9]+\.[a-z0-9]+$/i',
                                            
                      // == for Data Source ==                      // == for Data Source ==
Line 151: Line 151:
       $_SESSION['user'] = new Users( $customFields );       $_SESSION['user'] = new Users( $customFields );
    }    }
-</php>+</code>
  
 Note that since we replicated the basic structure of $dbDefinition in Users and usersDataSource, we can use the same hash to pass into both; they will store, but ignore values not relevant to them. Note that since we replicated the basic structure of $dbDefinition in Users and usersDataSource, we can use the same hash to pass into both; they will store, but ignore values not relevant to them.
Line 158: Line 158:
  
 This is not limited to adding new columns; you can modify the display definitions also, ie how the information is stored on the screen, to some extent. This is not limited to adding new columns; you can modify the display definitions also, ie how the information is stored on the screen, to some extent.
 +
 +=== New Column Definitions ===
 +
 +Note: If a new column is defined with the name (see below) of 'last password change', anytime a password is changed, it will be updated to the current date/time in YYYYMMDDHHMMSS format, which can be directly plugged into MySQL. The code is in there, but to not overpopulate the tables with columns that may not be necessary, I did not include this column in the default table structure.
 +
 +The structure of a new column only requires a value for 
 +  * type
 +  * html type
 +  * dbColumn
 +Defaults (generally empty strings) will be used for anything else.
 +
 +== key name ==
 +The key is used throughout the program to identify what column we are working on. It can be any value that can be used as a PHP hash key.
 +
 +== html type (required) ==
 +This determines how the field is displayed and processed during editing. Accepted values are:
 +  * text - standard text input field, corresponds to SQL varchar or char field
 +  * textarea - multi-line strings of arbitrary lenght, corresponds to mysql text field
 +  * boolean - displayed as checkbox, corresponds to mysql bool and/or tinyint (ie, 0 and 1 only)
 +  * password - displayed as a type='password' field, not pre-populated or displayed when typing. Uses varchar(128) in mysql for the length of the hash created
 +Any value not in the list above will probably result in weird errors.
 +
 +== dbColumn (required) ==
 +This is the column name in the database for this field, and all sql uses this value when accessing a column.
 +
 +== type (required for creating tables) ==
 +this is a valid MySQL database type used by the buildTable function to create the table, ie varchar, char, 
 +
 +== label ==
 +If set, will be the label for the input screens. If not defined, the label defaults to the key.
 +
 +== instructions ==
 +Replaces the html TITLE attribute for an INPUT, which is displayed by default on a hover. If not set, defaults to an empty string.
 +
 +== hint ==
 +Placed in the PLACEHODER attribute for an INPUT. Displayed in an empty text field most of the time. If not set, defaults to an empty string.
 +
 +== restrict ==
 +If set to true, will not be displayed when a user is editing their own record (so, not updateable by a user). Examples would be admin and enabled, which would not be something a user should change themselves. If an admin is editing a different user, these fields are available.
 +
 +== filter ==
 +If set, this is assumed to be a regular express. The result of the input is checked against the regex. If it does not match the regex, the update is declined and an error message displayed. By default, the username can only be alpha-numeric and an underscore, so the regex '/^[a-zA-Z0-9_]+$/' is set as the filter. If a user puts a period in their password, it will be rejected. Validity of the regex is not checked.
 +
 +== size ==
 +For database creation, if set, will create a column (like varchar) with this size, ie size='128' in a varchar field will result in varchar(128)
 +
 +== required ==
 +For database creation, sets the NOT NULL attribute to the column
 +
 +== default ==
 +For database creation, sets the DEFAULT attribute for the column
  
 ==== usersDataSource ==== ==== usersDataSource ====
Line 176: Line 227:
  
 ==== Future ==== ==== Future ====
- +  * I think I have a way of making it match things like INPUT TYPE='color' and INPUT TYPE='email'. I'm going to check that out. 
-This is only the initial part of this particular project. I now intend to extend both classes to allow boolean permissions which will be integrated into our new version of CAMP, giving very granular rights to users. It will be available as a second set of files in this repository and is planned for release by October 2021.+  This is only the initial part of this particular project. I now intend to extend both classes to allow boolean permissions which will be integrated into our new version of CAMP, giving very granular rights to users. It will be available as a second set of files in this repository and is planned for release by October 2021.
  
software/dailydata/libraries/php_user.txt · Last modified: 2021/09/22 01:30 by rodolico