Child pages
  • Classic Documentation
Skip to end of metadata
Go to start of metadata

Current Functionality Includes:
The list of recipients can be configured to included sets of roles from any realm. The display names of the roles is configurable.

Installation

Building the source

The source can be checked out from Subversion using the following command:

svn checkout https://source.sakaiproject.org/contrib/mailtool/

cd mailtool/trunk
maven

copy the resulting war in the target directory to your webapps folder.

NOTE: If you are building this against a 2.0.0 or 2.0.1 release, you will need to change "sakai-jsf-widgets" to "sakai-jsf-widgets-1" in the project.xml file.

Configuring the tool for each site

This tool has a large number of configuration options that can be seen from the Site Edit Tool. This is to allow the tool to be flexible for a number of situations now and in the future.

Example Configuration:

recipview = foothill

subjectprefix = Chem101:
displayinvalidemailaddrs = no (or yes)
emailarchive = /mailarchive/channel/YourSiteID/main

mail.newlock.siteid = /site/chem101

role1id = maintain
role1singular = Teacher
role1plural = Teachers
role1realmid = /site/chem101
role2id = access
role2singular = Student
role2plural = Students
role2realmid = /site/chem101

Descriptions:

For the roles you can do this up to 5 roles (soon to be 15). You have to fill out all 4 things for it to pick up the role.

  • recipview: Chooses the way that email recipients can be selected. Possible values include user, role, sidebyside, and foothill. Foothill has been the most tested.
  • subjectprefix: Will add the string to the beginning of the subject line for all emails sent.
  • displayinvalidmailaddrs: If this is set to yes, on the confirmation page after you send an email, there will be a list of all the recipients in the system that had blank emails in their profiles.
  • emailarchive: This gives you the option of having a checkbox on the GUI. If the user selects it, then the email will be appended to the corresponding archive.
  • mail.newlock.siteid: For this option you can specify a siteid that should be checked for the mail.new lock. This way you can control who can and can't send email, following the same permissions as the email archive. This is currently a very bad setup, since the tool will just take up screen space for most people. In the future this tool should just incorpate viewing the emailarchive, and then the send functionality can just be hidden for non-senders.
  • No labels