School "Letters Home" System

Don't know if I'm putting this in the right place, but I'd like some feedback

I was asked to create a "letters home" system for a group of schools. They spend a lot of time each week typing up letters, announcements of events and requests for permission for children to go on school trips, join clubs & so on. The idea is to publish these sorts of things on a TWiki site & invite replies.

This has meant that I've had to make several adaptions to the Wiki approach. This topic describes what I've done, invites comments on how to improve it and whether or not this adds to the general TWiki functionality or violates the spirit of Wiki systems.

The features I needed to introduce were:

• User Types - not just groups, I needed to give different functionality to different users.
• No visible TWiki Shorthand for some user types, only TWiki & html forms.
• Conditional Templates to vary the facilities available to user types, e.g. generation of documents and edit facilities are restricted.

Types of Letter

For now, we have three basic types of communications:

1. Letters: these just announce something & don't really require formal answers, like "We will be painting part of the school next week so classroom x will be closed".
2. Questions: things that do need a yes/no answer, like "the school play is next week can you come?"
3. Consent: this is the trickiest one, don't know what it's like in other countries, but in England this is a legal minefield, with the parents required to update medical forms ("has you child been exposed to a contagious disease in the last 4 weeks", "when did he/she last have a tetanus injection", that sort of thing). They want individual replies looking something like:

Consent from Parent for Visit to: Windsor Castle

On: 22 May 2006 from: 9:30 to: 15:15

I agree to AnthonyPerkins taking part in this visit and have read the information on the Consent Request

• I have reviewed and updated the medical records of AnthonyPerkins
• I confirm that my child is currently fit to take part in this visit and agree to inform the Group Leader immediately of any changes in my child's medical or other circumstances which occur between now and the commencement of this educational visit.
• I agree to my child's participation in the activities described.
• I acknowledge the need for my child to behave responsibly.

Signed ______________________________ CarlPerkins 16 May 2006

Where AnthonyPerkins is the child in question & CarlPerkins is the parent/guardian. Of course these are topic links in the live system.

Issues and Constraints

Firstly, these letters can be addressed to the parents of a class, a year, a "phase" (lower or upper school) or a school, or the whole group. They want to restrict parental access to the apropriate letters, mainly to avoid confusion, but also because they are keeping one eye on the idea of issuing end of term reports using this system, and that is obviously private information.

Parents also get to maintain their contact details, an alternate emergency contact & the family doctor. Doctor's details are open, but contacts should only be edited by the originator.

From my example abouve you can see that the schools wanted eletronic signatues, but also a backup of printed forms. The "Printable" display therefore isn't just the navigation & other links stripped away, but an imitation of the school letterhead paper.

The administration staff are the only ones permitted to generate letters.

The final problem is that not all the parents are confident with PCs or the Internet, so the school authorities wanted simple forms and yes/no check boxes & they certainly didn't want parents to have to learn TWiki shorthand. It's not that we don't trust the parents to operate in a Wiki environment or doubt their capability to learn the mark up, but some information is senesitve and we won't really have any opportunity for training. The administrators will use TWiki notation, but they are limited in number and we will support & train them.

So, what I have done is:

Variable Pages and User Types

I created nested groups (class within year within phase within school) to control access permissions.

Users are divided into "types" rather than just groups, by creating a set of topics which can only be viewed by the approriate set of groups & then including in the WebPreferences variable set tings such as:

   * Set ADMIN = %SEARCH{"Set" regex="on"  topic="MemberOfAdminGroup" scope="text" noheader="on" nosummary="on" nosearch="on" nototal="on" format="true"}%

So the search returns "true" if the MemberOfAdminGroup is visible & this can be used in statements like

%INCLUDE{"%IF{"%ADMINMEMBER%" then="AdministrationTasks" else="EmptyTopic"}%"}%

If this could be done in an easier way, I'm open to suggestions. The idea is to reduce membership of TWiki groups to a simple "am I allowed to do this?" test.

From that last statement it's obvious I'm displaying variable pages, tailored to the groups the user belong to, with different page elements displayed to each type, currently parents, staff & developers

"Mini Forms"

Some repsonses from the parents are quite simple, yes/no or "I've read it".

For these the CommentPlugin proved to be very useful. One new template for it provided the yes/no response facility. Others act as "mini-forms" which can update a page, - and then the admin staff can see all the responses at the bottom of the letter they sent out.

For example to mark a pages as read, just so the admin team know if the parent has accepted a document, I put this on the letter.

%COMMENT{type="read" target="%WEB%.%TOPIC%#InsertHere"}%
<!--
#InsertHere
| Read | %MAINWEB%.ChrisHogan |  13 May 2006 - 19:18|

The "read" is a CommentPlugin template which only has a button to click, no input area at all. The hidden area can be "revealed" by a search by the admin users.

---------------------------------------------------------------------------
---+++ read
%TMPL:DEF{PROMPT:read}%
<input %DISABLED% type="hidden" name="readmark" value="Read" /> 
<br />
<input %DISABLED% type="submit" value="%button|Mark as Read%" />

%TMPL:END%

%TMPL:DEF{OUTPUT:read}%%POS:AFTER%| %URLPARAM{"readmark"}% | %MAINWEB%.%WIKINAME% |  %SERVERTIME{}%|%TMPL:END%

---------------------------------------------------------------------------

Hiding TWiki Shorthand

I had to create a fair number of html forms with TWiki forms & templates for the Letters, Questions and Consents, as well as for Doctor, Contact & Pupil info.

The Pupil records have EditTablePlugin forms for some data, but for the Contact and Doctor editing, the parents get taken straight through to the form input without seeing the TWiki text area, though in one case this means giving them just an set of save/cancel buttons, as there aren't any form fields, it's all been included via URLPARAM.

For example, when Editing a Doctor, in addtion to the displayed form fields with the contact details, we have a simple search which lists the children he/she is the General Practioner for, but I don't want the parents to edit this, so we have a link to the TWiki topic editor which just displays the form data:

%STARTSECTION{"editdetails" type="section"}%
<a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%MYTOPIC%?action=form&t=%GMTIME{"$epoch"}%">Edit Details</a> 
%ENDSECTION{"editdetails"  type="section"}%

This is included so that the %GMTIME isn't "frozen" at topic create time. In fact, several sections are included to make the html forms behave just as we wanted them too.

Variable Templates

I had problems which turned out to be the way certain variables were expressed on creation of a topic from a template, I got round it with includes, but I was having great problems with the skins.

I tried creating a variant of the PatternSkin, but the one which is downloadable, separately from release 4.0.2 is not the same version (something which took a whole day to sink in), so my tests never quite matched up with my expectations.

In the end, I decided to go for conditional displays within the PatternSkin, substantiating different elements of the tool bar, for example, according to the type of use logged on. Again, I know that this wasn't possible with earlier releases that 4.0.0 - and it certainly wasn't easy with 4.0.2. I had to split the evaulation of my templates by creating topics containing piece of template & using includes in the tmpl files to be able to evaulate my "user class" variables & dynamically include the fragments.

For example in the viewtopicactionbuttons.pattern.tmpl I put

%TMPL:DEF{"editparent"}%%INCLUDE{%TWIKIWEB%.%IF{"$ PARENT ='true'" then="LettersHomeInactiveEdit" else="LettersHomeActiveEdit"}%}%%TMPL:END%

%TMPL:DEF{"activatable_raw_edit"}%%TMPL:P{context="inactive" then="inactive_edit" else="editparent"}%%TMPL:END%

The LettersHomeInactiveEdit Topic Template contains something like:

%STARTINCLUDE%
%TMPL:P{"inactive_edit"}%
%STOPINCLUDE%

And the LettersHomeActiveEdit Topic Template contains something like:

%STARTINCLUDE%
%TMPL:P{"editrawbase"}%
%STOPINCLUDE%

Printing

MY Print Skin is set to show the header & footer including the school logo from their letterhead. The online display looks a little odd, with the footer stuck at what looks like an arbitarty location on the screen, but it prints OK. I'm using CSS to place the footer where it should be on an A4 sheet/

Note on Conditional Set statements

The documentation says:

The IF statement is deliberately kept simple. In particular, note that there is no way to conditionally execute a Set statement. If you need more sophisticated control over formatting, then consider using the SpreadSheetPlugin.

But consider

   * Set FRED = Fred
   * Set BLOGGS= Bloggs
   * Set TEST = istrue
   * Set NEW1= %IF{ " '%TEST%' = 'istrue' " then="%FRED%" else="%BLOGGS%"}%
   * Set NEW2= %IF{ " '%TEST%' = 'nottrue' " then="%FRED%" else="%BLOGGS%"}%

NAME1 & NAME2 are certainly set to different values according to the condition, but you CAN'T reset FRED as the 2nd set of FRED is parsed before the IF statement - which could give totally horrible results, for example:

   * Set FRED = %IF{ " '%TEST%' = 'istrue' " then="%FRED%" else="%BLOGGS%"}%

However if you aren't trying to overide a variable from another topic, or reset one set earlier in the topic, then using interim values (like FRED and BLOGGS) lets you conditionally set variables such as NAME1.

Conclusion

This has rambled on a bit too much, I think.

Is anybody interested in more detail of what I've done? Has anybody got ways of doing some of this more easily (I don't claim to be a TWiki expert)?

-- ChrisHogan - 14 Aug 2006

-- Contributors: ChrisHogan - 15 Aug 2006

Discussion