Category: User Administration (Registration, Login & Banning)

{syntax type="tiki" editor="plain"}
I want to allow registration without E-Mail.
Even though I have disabled all E-Mail checking it reports a validation failure.
The function validate_email called in tiki-register.php does as first task a format check on the E-Mail and returns false if the format is wrong. Emptpy emails result in false too.
Is this a valid decision at this point?

Registrations set to require validation by admin do not send email to configured email addresses any more. It use to work as expected, as far as I know, in 15.x

We have set the 3 email addresses separated by commas, as indicated in the Tiki UI, in case it matters, to receive the emails warning about a validation is pending

Ref: aspb-sg

Introduced in 1.9.9 and fix in 1.9.10.1

See sylvieg or kerrnel22 for details

The "Remember me" feature of login on tw.o sites doesn't really work as it should. On tw.o, dev.tw.o and themes.tw.o it's set via Admin > Login to values "tikiwiki, .tikiwiki.org, /, 1 week" and it lasts only some hour or so and expires then. It's annoying to relogin many times a day.

So, in case someone hasn’t reported it yet; the “I forgot my password” functionality doesn’t work in 1.9.0.

It sends the email fine; but the password included in the email does not work.

Before I start going through the code can anyone explain how the passwords work?

So far I get:

- that the “hash” field is md5(“username” + “password”)
- when I do the “forgot pw” thing it sets the “provpass” field with the pw sent in the email
- md5 of user+provpass though does NOT equal “hash”

I suspect code would be something like:

- if user logs in and there is a provpass set then validate against that password
- and then foprce user to change pass
- then use their new entered pass to make hash and delete provpass

Does this seem about right???

I had two usergroups, then added a third, then went in to remove a user from a group from the Admin Users page. If I go into Admin Groups and click on a group and then go down to Show Users in Group, it shows the correct list with the appropriate users missing from the group that I had removed.

If I go into Admin Users, the list of users shows up and if I look at the line entry for the users I removed from ABC group, the group shows up in italics (''ABC'').

Unless there is a cleanup function I'm unaware of, I think this may be a bug. I'm running 1.9.7 according to the README.

This has also been reproduced on the http://demo.opensourcecms.com site.

I created a user. Then I'm trying to remove the "Registered" group from the groups associated to that particular user. When I click on the little x next to the group it disappears from the user's groups. Then I created a group named "blocked". This group only inherits from the anonymous group. It is created basically to prevent a user from having more permissions than an anonymous user, without removing the account (in order to reactivate the permissions at a later time). What I actually want to do is to deactivate some accounts and reactivate them later. So limiting the permissions to that of an anonymous user seemed an appropriate course of action. After removing the "Registered" group from the user's list, I assign him the blocked group only. This blocked group include the anonymous group and that's it. But, when I go to see the blocked group's permission(it has none of its own), I see some permissions inherited from the anonymous group (which is what I asked for) but I also see the tiki_p_edit permission inherited from the "Registered" group (which is NOT what I asked for). So it seems to me that when you have a user, it belongs necessarily to the registered group. And when you remove that group from the user's group list, it doesn't seem to have any real effect aside from not showing that group in the list. It would be interesting to remove that registered group from some users to deactivate their account temporarily. In any case this seems a bug, either removing Registered should have the expected effect, or it should not be possible to remove that group at all. I would opt for the first alternative.

Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1124

Unassigning several users from a group fail, only one is removed.

Check the instance;
Go to : http://bsfez-11581-6534.show.tikiwiki.org/tiki-admingroups.php?group=The%20group#contenttabs_admingroups-3

Try to unassign more than on user from the "The group". Only the first one is removed.

It is possible to list all users in a given group. However, to remove them from the groups, we need to go to another page.

We should be able to remove users from groups on this page:
tiki-admingroups.php?group=Registered&show=1

I visit a page and it says I must login. Since I have no account, I register.

At the end of the registration process, I should be sent back to the page I was trying to access.

Review all mods and decide what should be added to BRANCH-1-10
http://mods.tikiwiki.org/

Please see: ((To mods or not to mods))

criteria:
*license
*size
*security
*potential popularity of feature
*non-reliance on 3rd party code


Plugins that will now be in core (and removed from mods):

*include ok in 2.0, should be removed from mods
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm|perm]
*group (ok) should be removed from mods: wikiplugin_group.php
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=files|wikiplugin_files.php]
*wikiplugin_listpages.php ok?, just remove from mods?
*[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1550|wikiplugin_mouseover.php needs to be fixed, then moved]
*wikiplugin_trackeritemfield.php __done in 2.0__

Reason:
*Great plugins
*Mods installer doesn't work for everyone and there is no documentation for manual install

Copied some suggestion I just throwed on irc..., after fighting each time on some of my production sites to manually send messages to many users which are kind of lost some times at the beggining of their participation in a tiki-site-powered community.

{QUOTE()}
(11:37:39) xavi: I was just wondering about a new and easy improvement of the registration process of new users to a community sit eusing tiki
(11:38:07) xavi: just through allowing an admin to add acustomized welcome message to new users successfully registered to the site...
(11:38:29) xavi: ... with the text and links he might need to tell to new users....
(11:38:52) xavi: ...in a similar way to what mailman does for the welcome message to new users...
(11:39:48) xavi: ...I imagine a simple text area, like site identity does, where the admin can write any simple text (with or without wiki markup? like the newsletter feature does/allows)...
(11:40:45) xavi: ...so that the admin can set that message easily (without manualy searching for the appropiate template to hack through ftp)...
(11:42:48) xavi: ..and the the new user, can review the infos and tips that he/she needs to know on that site: "now you can: # watch that forum where that important thing is discussed.... #join that newsletter/blog/articlefeature to be up to date about news from that community, #review and/or subscribe to that tracker..., ...
(11:45:22) xavi: oh well, I can't code php+mysql myself (yet, at least ;-) ), but I guess that this shouldn't be that difficult nor time consuming to an experienced coder, provided that that person agrees on that this feature is "low hanging fruit" to improve the experience of newcomers to a community, through improving the communication while the first steps of that person in the community site...
{QUOTE}

This could also be important for ((Workspaces)), and ((Organic Groups)). So that, not just to register (join the registered group), but as a customized message per group, so that, when joining a new group (at registration time, or later on through the subscribe groups plugin), you get the specific message with hints, links and remindings of things adapted for that group.

Selecting a group at registration time doesn't assign that new user to that group since a site was upgraded from 15.x to 17.x (svn r63071)

ref: aspb-sg

{syntax type="tiki" editor="plain"}
The ((doc:Inter-User Messages)) system is quite nice.

However, it means:
1- That users have duplicate mailboxes
2- And the recipient can't just click reply

On dev.tikiwiki.org, this is not so nice because people already have an internal tiki mailbox on tikiwiki.org

So, let's think about an additional/modified feature called "direct message" or "direct mail".

This would simulate a regular email. (let's plan ahead that this should be able to send other types of messages (jabber, sms, etc.)

The headers could be:
"from" is Full Name ({$Username}) {senderemail}
"to" is Full Name ({$Username}) {recipientemail}
"bcc" to {senderemail} (So we have a trace of what we sent)

In case some spammers get a hold of it, let's have something like this at the bottom:
This message was sent via {$name of site}


Not sure if this should be done with the ((doc:webmail)) feature, or maybe as an option of ((doc:Inter-User Messages))

See how MediaWiki does it for a good example:
http://en.wikipedia.org/wiki/Special:EmailUser/Marclaporte

We already have in version 3.0 on tiki-admin.php?page=login

On permission denied, display login box for anonymous:
On permission denied, send to this url:

Similarly, it would be nice to send people to a specific URL or wiki page upon logout.

Ex.:
"Thank you for visiting"


Some ideas for the future. We should have a section in the admin panel "login/logout/navigation" with things like:

redirect on login (which is group home pages)
redirect on user account validated. Ex.: Wiki page "Thank you for registering"
redirect on logout. Ex.: Wiki page "thank you for your visit"
Close site (except for those with permission). Ex.: Wiki page "The site is closed for maintenance"
Close site when server load is above the threshold (except for those with permission). Ex.: Wiki page "The site is under pressure."
On permission denied, display login module (for Anonymous). (as it does now)
etc.

Also on tiki-admin.php?page=features
Redirect On Error
Custom Home

When you set some expiry time for a group membership (through the admin groups interface), this information is stored in mysql table users_usergroups, and this is taken into account when you use ((doc:PluginMemberPayment)).

However, in other cases of letting a user join a group which has some expiry date set, that information (expiry date) is not stored at mysql table users_usergroups as expected.

Reproduced here:
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

You can also test with a few users already created:
u: foo1
p: 12345

or
u: user1
p: user1

Cases:
!!! a) Through usual Registration
if you set some group to be selected at registration time
You can register a new user to test case (a), and select either Group1 or Group2 at registration time (both have expiry date 2 days later):
http://xavi-9794-5946.show.tikiwiki.org/tiki-register.php

!!! b) Through Plugin subscribegroup
if the user clicks at ((doc:PluginSubscribeGroup)) (with perms and site config set up appropriately),
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#Plugin_subscribegroup

!!! c) Through Plugin MemberList
if the user selects to join him/herself thorugh ((doc:PluginMemberList))
(with perms and site config set up appropriately), or the admin join a user to that group
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginMemberList

However, looking at the user through tiki-assignuser.php?assign_user=foo , the right expiry information is shown.
http://xavi-9794-5946.show.tikiwiki.org/tiki-assignuser.php?assign_user=foo1

But if you use ((doc:PluginGroupExpiry)) (which looks for that date at table users_usergroups) no date is found and it reports back that the group membership never expires.
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginGroupExpiry_info

In addition, it seems that someone already noticed that type of issue, and this comment can be found in lib/userslib.php > function get_extend_until_info:
{CODE()}
(...)
function get_extend_until_info($user, $group, $periods = 1)
{
//use these functions to get current expiry dates for existing members - they are calculated in some cases
//so just grabbing the "expire" field from the users_usergroups table doesn't always work
(...)
{CODE}

---
Update {sign user="xavi" datetime="2016-05-27T14:38:26+00:00"}:
* this issue seems to be fixed in Tiki 15.x (as of r58705, at least). The 3 use cases work as expected (nice!). The extra code in 15.x would need to be backported to 12.x, I guess.
* Assign user to groups has got a regression in 15.x: you cannot see (nor even edit) the group expiry date through the standard user administration UI in 15.x: when you click in "add or remove from a group" in 15.x, you are sent in a modal to this type of url:
+ __tiki-ajax_services.php?controller=user&action=manage_groups&checked=foo1&all_groups%5B0%5D=Admins&all_groups%5B1%5D=Anonymous&all_groups%5B2%5D=Group1&all_groups%5B3%5D=Group2&all_groups%5B4%5D=Registered&offset=0&sort_mode=login_asc&numrows=25&modal=1__
+
+ and no expiry information is shown.
+
+ While in Tiki12, you are sent to:
+ __tiki-assignuser.php?assign_user=foo1__
+
+ This has been added as a new bug report, since it's another issue (regression):
+ [item5953]

Seen on IRC:
{img src=images/code.png}%%% {CODE(wrap=>1)}
(10:33:47 AM) ***dthacker also wonders if there is a login-timestamp wiki syntax such as mediawiki's ~~~~ that would auto sign with user id and date/time.
{CODE}


Wiki pages are great to produce Neutral Point of View (NPOV) content. If we need to know who added what, we check the edit history.

For debates, discussions, opinions, etc, people will often use Tiki blogs, Tiki forums or comments at the bottom of wiki pages. These are more natural formats and it's clear who thinks what and who said what. Comments & forum threading make it clear who is responding to who/what.

However, in some cases, it is useful to have this type of interaction in wiki pages. The [http://doc.tikiwiki.org/Editorial+Board|TikiWiki documentation Editorial board] has monthly meetings to discuss and make decisions. Members can edit, comment and vote on motions.

The way people add their comments is not standard and if we are not careful, it can get messy. This often happens in wikis.

Some wikis use a special syntax for "signature". This would be a way to associate the name of the user and maybe the date to a specific comment. It would be nice to clearly and visually associate the user to the comment. Maybe the comment & signature are in a same box?

It would be nice also for people to be able to express support to an idea in the wiki page, with a thumbs up (+1) or a thumbs down (-1). Right now, the wiki ratings feature let's us vote only once per wiki page.

These syntaxes should be quicktags to it's easy to add. Maybe some of the less important meta data (ex.: date of comment) would be only visible on mouse-over. (and thus not in printed mode). The mouse over could also contain a link to the user's personal wiki page and some data about the user (his avatar, score, etc).


Ex.:
*click my PluginComment tool (in toolbar)
*Pre-fill text that will be mouse-overed with previously selected text
**add date & signature (with link to userpage)


Everyone: please share your ideas on this and how you have seen it implemented elsewhere.

Thanks!


Related:
{wish id=2102}

The ID generated by get_user_cache_id is used to create a new directory in templates_c/ . This ID is generated by concatenating all the groups a user is in.
When a user is in many groups the ID exceeds the maximum filename length of my system (FreeBSD 4.11).

Trying to login with LDAP servers (including Microsoft Active Directory) fails due to an internal server error which occurs in tiki-login.php. The page obtained is blank.
$userlib->validate_user($requestedUser, $pass, $challenge, $response);

Authentication with local accounts still works.

This regression was introduced by r60747, which was backported to branch 12 in r60750.

[https://dev.tiki.org/item6283|Ticket #6283] is a duplicate of this one.

Even though global perms allow viewing wiki pages (to Anonymous, for example), assigning an edit perm to another group for a specific wiki page overrides the view perm and Anonymous can't see it anymore unless a specific tiki_p_view perm is assigned to the page for Anonymous.

this is a feature - it is how it works . As soon as you hjave a special perms, you need to redefine all the perm for the page

Every time a new object gets created (wiki page, blog entry etc) the item recieves only global permissions.

It would help a lot if the admin could define 'standard permissions' for each group for specific features.
(needs to be integrated with improvements to "permissions by category" introduced in 1.9 - which provides a coherent approach for "object" based permissions to compliment user based perms.)

To keep wiki pages inside the group, the admin would assign the read right only to that group, and a member of that group posting a new item would not have to worry about security as much.

Am not sure what to do when user is member of multiple groups... maybe she can select in a drop-down which is the one that wins, or maybe the admin determins that when creating the user?

Reccomendation: Inherit permissions. (particularly for wiki)
The default behavior for a new object should be to inherit permissions from the page it was created from (global if none). Particularly in a wiki, this would facilitate the use of "private areas" - key feature for tikiwiki as groupware so committees. groups, etc. can operate in privacy, if so desired. Whoever create the page should be able to disable this inheriting, but it should be on by default. Admins can then create private wiki spaces by customizing perms on one page (the group home page).

I have encountered a few snags after upgrading from Tiki 1.9.11 to 2.0

One of the problems is that I am unable to register / add users, because of the following error message:

An error occured in a database query!
Unknown column 'email_confirm' in 'field list'

This happens on
tiki-register.php (registration) and tiki-adminusers.php (batch upload / add)

Is there a fix for this?

Seems like Tanzania keeps falling out of the country list. This was the case some years ago. Might as well add Swahili as a language option if applicable.

I have an error when I try to add a new user:

{img src=images/code.png}%%% {CODE()} Context:
File tiki-adminusers.php
Url tiki-adminusers.php
Query:
insert into `users_users`(`login`, `password`, `email`, `provpass`, `registrationDate`, `hash`, `pass_confirm`, `email_confirm`, `created`, `valid`, `openid_url`, `lastLogin`, `waiting`) values(?,?,?,?,?,?,?,?,?,?,?,?,?)
Values:
0 trenad
1
2 n.trepanier@rrsss16.gouv.qc.ca
3
4 1224014104
5 $1$98TWiy55$sm3YVgaZTDG8wTR6O9kvz0
6 1224014104
7 1224014104
8 1224014104
9 NULL
10 NULL
11 NULL
12 NULL
Message:
Unknown column 'email_confirm' in 'field list'
Built query was probably:
insert into `users_users`(`login`, `password`, `email`, `provpass`, `registrationDate`, `hash`, `pass_confirm`, `email_confirm`, `created`, `valid`, `openid_url`, `lastLogin`, `waiting`) values('trenad','','n.trepanier@rrsss16.gouv.qc.ca','','1224014104','$1$98TWiy55$sm3YVgaZTDG8wTR6O9kvz0','1224014104','1224014104','1224014104',NULL,NULL,NULL,NULL){CODE}

Do you guys have any idea what is happening.