[SAK-28184] New Account tool should email users a link to activate their
accounts Created: 12-Dec-2014 Updated: 10-Feb-2016 Resolved: 23-Mar-2015
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
Sakai
Account, Reset Password & Account Validation
11.0 [Tentative]
Type:
Reporter:
Resolution:
Labels:
Contributed Patch
Priority:
Brian Baillargeon
Assignee:
Fixed
Votes:
PATCH_ADDED, defaultfalse
Attachments:
Issue Links:
11.0 [Tentative]
Major
Brian Jones
0
SAK-28184.patch
Depend
is depended on
by
SAK29182
New Account tool should respect
inval...
Resolved
Yes
Property
addition/change
required:
Previous Issue
Keys:
Description
To ensure that users are creating accounts using their real email addresses, the New Account
tool should be configurable to send an email with a link to activate their account.
Also, when we add unofficial participants through Site Info, the user eids match their email
addresses. For consistency, the New Account tool should have configuration to similarly force
the eid to match the user's email address.
Finally, it would be handy to display instructions in the tool. But note that institutions may have
multiple instances of this tool to serve different purposes (eg. to create users with different
account types), so the instructions should be configurable in the tool properties.
The following tool properties are introduced in the New Account tool:
create-blurb=(text, ie. "Please enter your account details below")
force-eid-equals-email=false (default)
^ If true, removes the field for the user to type their own ID. The eid will be the user's email
address
validate-through-email=false (default)
^ If true, integrates with account-validator. Ie. User creates inactive account, email is sent
containing a link, user navigates to the link, fills form to complete / activate their account
Comments
Comment by Brian Baillargeon [ 12-Dec-2014 ]
Attaching patches. Files matching '*_w.patch' ignore whitespace for increased legibility, but
please do not apply these files; the other ones handle indenting properly.
Comment by Brian Baillargeon [ 15-Dec-2014 ]
Re-uploading user patches; fixed a javascript error that prevented the 'Create Account' button
from enabling when the tool is configured with:
validate-through-email: false
force-eid-equals-email: true
Comment by Brian Jones [ 16-Dec-2014 ]
When you say "the New Account tool should be configurable to send an email with a link to
activate their account", what are you referring to in terms of being able to configure it this way?
Does this introduce a new sakai.property? I didn't see one referenced in either of the patches.
Same question for "the New Account tool should have configuration to similarly force the eid to
match the user's email address."
Comment by Brian Baillargeon [ 17-Dec-2014 ]
There are use cases where you may want to have multiple New Account tools with these
properties configured differently. So the configuration is not in sakai.properties, but in the tool
properties (as managed by the Sites tool in admin workspace)
Comment by Brian Jones [ 17-Dec-2014 ]
Got it; thanks.
Comment by Matthew Jones [ 18-Dec-2014 ]
Can you delete any old patches from this? If you create a pre-commit review on
https://crucible.sakaiproject.org/ we can review the code there.
Comment by Brian Baillargeon [ 18-Dec-2014 ]
Created https://crucible.sakaiproject.org/cru/SAKTRUNK-100 using the '_w' patches (created
using 'svn diff -x -w'); should this be committed, the opposite files should be used.
Comment by Brian Jones [ 19-Mar-2015 ]
I have closed the Crucible review in favour of turning this into a PR, which is linked.
Comment by Brian Jones [ 23-Mar-2015 ]
Attaching patch as applied to trunk
Comment by Brian Jones [ 23-Mar-2015 ]
merged PR 311; e4233bd
Comment by Neal Caidin [ 19-May-2015 ]
It looks like the Properties addition flag should be checked (yes) on this ticket?
Comment by Brian Jones [ 20-May-2015 ]
Yes, thanks for catching that Neal.
Comment by Neal Caidin [ 27-Jan-2016 ]
Thanks. I don't see these properties in default.sakai.properties. Could they be added please?
Should I add a separate Jira for this?
Comment by Neal Caidin [ 27-Jan-2016 ]
Okay, I just actually read the email from Paul L. (see below). But I think it should still be
documented in default.sakai.properties, even though it is not set there. That way, there is one
place to document Sakai configuration. Does that make sense or is there a better idea?
From Paul Lukasewych:
""validate-through-email" is actually a tool property that you set on a
per-instance basis, not a property set via the sakai.properties file.
This was done because institutions could have multiple instances of the
new account tool, for example to create users with different account types.
To set this property, you will have to use the Sites tool under Admin
Workspace to find the site that the instance of New Account has been
added to (probably !gateway), then go to Add/Edit Pages, find the page
that houses the tool, find the tool and then edit its properties. You
should then be able to see the "validate-through-email" property and
change the value to true.
"
Comment by Brian Baillargeon [ 28-Jan-2016 ]
I agree that it would be useful to document tool properties like this if a strategy doesn't exist
already. But I think it would be unclear adding non-sakai.property configuration into
default.sakai.properties. You'd have to explain something like "# This is a tool property; not a
sakai.property:" before each tool property, and possibly specify the servlet-name.
Tools are usually configurable within their own UIs by maintainers, so I think tool property
configuration like this comes up typically for gateway tools / special cases that require
administrator attention. So I'd imagine that the existence of tool properties like this aren't very
well known within the Sakai community.
I'd be more in favour of having a separate file in the config project listing the tool configuration,
with a reference near the top of default.sakai.properties like:
"For tool configuration see toolConfiguration.txt" or such.
Since the sites tool indicates tool names by their servlet name (ie. "sakai.createuser"), it might
make sense to group tools in such a file like:
##### New Account (sakai.createuser) #####
Page configuration could be handled similarly.
Would that make sense?
Generated at Sat Mar 05 21:25:59 CST 2016 using JIRA 6.4.11#64026sha1:78f6ec473a3f058bd5d6c30e9319c7ab376bdb9c.