mudmin / userspice5-dev

UserSpice 5 Dev Channel - Note this is PRE PRE PRE PRE Alpha at best. Not for production use.

UserSpice5-Dev

UserSpice 5 Dev Channel - Note this is PRE Alpha at best. Not for production use.

The UserSpice 5 channel is intended to permit larger or more significant changes to the code base. There is still a lot of work that needs to be done.

To get started you will need to rename users/db_cred.config.php to users/db_cred.php and fill in the empty values.

You will need to manually import the sql dump located at git location sql/userspice5.sql . This is a "sanitized" dump, which should be free of credentials. After the import, you can edit the settings table and fill in the following keys:

site_name (e.g. My Site)

site_url (e.g. https://example.com/)

If you are using recaptcha, then you need to put your keys in here:

recaptcha_private (e.g. google test key is 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe)

recaptcha_public (e.g. google test key is 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI)

If you are using the Google login, then you will need to enter your id and secret here after obtaining them with these instructions

https://developers.google.com/api-client-library/php/auth/web-app#creatingcred

gid (i.e. this is the Client ID)

gsecret (this is the secret/private key)

If you are using the Facebook login, then you will need to enter your id and secret here:

fbid (i.e. this is the App ID)

fbsecret (this is the secret/private key)

userspice5-dev's Issues

Allow custom fields to be added to key tables

Allow an administrator to add custom fields with a limited set of types and they get stored in custom fields which are already included in these key tables.

Thus US would distribute with users.custom1, users.custom2, users.custom3 as unused but available fields

A separate table "custom_fields" would allow choosing a table and a label for these custom fields.

In the form(s) after the normal fields are added there would be a generic "add_custom_fields('users')" or something like that which would read this table and set things up for editing/validating/etc.

When track_guest setting is off, error in init.php

If you turn off track_guest (in the settings table) then user_id doesn't get set in init.php and you get errors

Allow clicking on hint-icon to see hint-text

Currently you can see the hint-text by hovering over, but there is a slight delay before the hover takes effect. Some users might go straight there and click immediately - in that case something sensible should happen which would seem to indicate showing that text.

See http://jsfiddle.net/9mmmwum4/2/ or similar

It would be good if we could figure out a way to make it look the same as the hover-over, but that may get into some browser-dependent code...

Allow validations to be edited by admin

Validations are increasingly being stored in the database. There needs to be a way for the administrator to edit these.

(For instance, 1 admin might want to make "users.company" non-required, another site might want to allow spaces in usernames, another site might want more secure passwords to be required, etc.)

Validate::describe() needs to be translatable

Use lang() codes for each element, possibly even for punctuation?

Implement client-side validation with Form and FormField and Validate classes

If we have all the validation information available, all that is needed is to implement client-side validation as well with pretty icons to indicate required/optional/validated/invalid/etc. (http://bootsnipp.com/snippets/6aGm)

We wouldn't have to validate everything - just the ones that can be done fairly easily... At least at the beginning.

fixing header/menu overwriting top of form

Sometimes (http://userspice.com/forums/topic/page-formating-bug/, http://userspice.com/forums/topic/navigation-covering-data/) the top of a form gets covered up by the UserSpice header and nav. (This can be reproduced by using a bigger image which covers more vertical pixels in place of the UserSpice logo.)

If we put the header/nav inside of bootstrap rows would that solve the problem?

Perhaps

could be in header.php and

could be in page_footer.php or something like that?

This is all theoretical in terms of the fix - but the problem does occur sometimes.

Implement force-password-reset feature

This will be especially useful if someone has added a bunch of users via CSV or something

Mark *all* required fields via validation class

Currently hint-text is provided for fields. It would be good if an asterisk (or some other icon) were marked for required fields.

Check to be sure everything is UTF-8

See http://userspice.com/forums/topic/pdo-newbie-loop-question/

Everything in the database and all HTML pages should be set for UTF-8 in order to facilitate translation/language issues.

(It may already be like this - I'm just making a note of something I want to check)

Allow read-only access to all pages implemented via Classes/form.php

A group could be given access to a page but with read-only access specified. In that case a "disabled" or "readonly" attribute would be added to each input field and no DB update/insert/delete would occur.

See http://userspice.com/forums/topic/function-level-access-control/

This could also be extended to allow not just "everything" (as it is now) and "readonly" but various other "modes". Thus a group administrator (NOT a system administrator) might be able to see or modify part of a form but not the whole form...

Must identify where US5 branched and implement all fixes in US4 from that point

For instance, analytics...

Basically we don't want any bugs that were fixed in US4 to be re-introduced into US5

Add a page_title column to the pages table

See comments in http://userspice.com/forums/topic/v-5-didnt-know-where-else-to-post-this-so/

Obviously needs to respond to lang() - maybe a language token stored there rather than a simple string?

It should update both the browser page-title as well as the title printed on the page.