Changes between Version 1 and Version 2 of Ticket #5374, comment 8
- Timestamp:
- 02/14/2014 12:43:27 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #5374, comment 8
v1 v2 5 5 Even though the ticket is specifically designed to improve the management of signups from a site admin back-end point of view, I think functions that you've introduced such as {{{check_user_status}}} pave the way for a far more friendly front-end registration process. 6 6 7 For instance, if a user with {{{user_status == 2}}} were able to sign in before activating their account - {{{check_user_status}}} could be used to disable important functionality for these users such as compose messages, update profile, activity comment etc whilst still allowing them to browse around as a logged in member. I've found the requirement to visit their email account and click the activation link before they can log in is off-putting for a subset of users - almost like closing the door in their face. Giving them a 'lo gged-in glimpse' of what they can do on the website might motivate more users to visit their email and hit the activation link.7 For instance, if a user with {{{user_status == 2}}} were able to sign in before activating their account - {{{check_user_status}}} could be used to disable important functionality for these users such as compose messages, update profile, activity comment etc whilst still allowing them to browse around as a logged in member. I've found the requirement to visit their email account and click the activation link before they can log in is off-putting for a subset of users - almost like closing the door in their face. Giving them a 'locked-down glimpse' of what they can do on the website might motivate more users to visit their email and hit the activation link. 8 8 9 9 Apologies if this went slightly off-topic but reading through your patch gave me the idea.