I have to concur with Mike's analysis here -- the problem is we can't
just keep adding things to interpret 'automagically' because at the end
of the day, it's an email. It isn't an environment designed to support
multiple variations of a command -- what if I  want to discuss digests?

I *fully* appreciate, Steve, that you want to assist the users in
getting their job done -- but while digests are a *very* highly used
feature, consider this:

 - over 1/3 of users in the MPLS group of forums.e-democracy.org have it
switched on
 - how many of those 330 odd users have needed help in switching it on?

I can see 2 emails in the MPLS which look like digest related accidents
since October 2004, roughly 4 years. Add the one you had recently, and
then triple it. That would be 9 out of 330 (and in a group of 900 odd).
So less than 1% of the group has experienced digest command issues (and
actually, the issues I can see are with leaving the digest mode).

> I know GroupServer catches many partial commands, here is one more to
> add to the list - the word digest by itself.

The mailing-list interface is a command-line interface that is, and
should be, intolerant of mistakes. If you try and be cleaver, you end up
with a Do What I Mean (Dwim) interface, which is a BAD THING®. If the
people want an easy to use interface, that is tolerant of mistakes, then
we have a lovely Web page for doing what they want.

How about adding a link to turn the digest on in your footer?
  mailto:<email obscured>?Subject=digest%20on

I know GroupServer catches many partial commands, here is one more to add to
the list - the word digest by itself.

I created a new version of GroupServer, and it seemed to build ok.
However
      * I lost it in a reboot, so I need to check it out again
      * I used my old Zope data
      * I used my old PostgreSQL data
So I take its "going" status with a grain of salt!

On Mon, 2008-07-28 at 16:48 +1200, Michael JasonSmith wrote:
> /headdesk
>
> There is no a in bed.

Not the last time I looked :-)

/headdesk

There is no a in bed.

Hi Michael,

It looks like you've misspelled "testbed" as "testbead" ...

A.

On Mon, 2008-07-28 at 16:35 +1200, Michael JasonSmith wrote:
> Ask me why I hate databases. Go on, ask me!
>
>   mpj17@manu:~$  createdb -U testbed -E UTF8 testbed
>   createdb: database creation failed: ERROR:  database "testbed" already
exists

Ask me why I hate databases. Go on, ask me!

  mpj17@manu:~$  createdb -U testbed -E UTF8 testbed
  createdb: database creation failed: ERROR:  database "testbed" already exists
  mpj17@manu:~$ psql -U testbead testbead
  psql: FATAL:  database "testbead" does not exist

Richard,

I was trying to set up, or connect, to a local database on my new
(Alice's old) machine, but as *%# %$@# always, database security gets in
the way of doing anything strait forward ☺ Any suggestions?

Thanks for the advice, Richard. I will keep it in mind as I think about
where the different methods should go ☺

On Thu, 2008-07-24 at 17:15 +1200, Michael JasonSmith wrote:
> I have finished the conversion and testing of the new Can the User Post
>  code, which I have been working on. I have come across some rather
>  interesting properties of GroupServer mailing lists that I had not
>  seen before.
>
> One is the ability to block messages from a particular email address.
>  Currently, if this happens, the message is dropped, without any
>  notification. Should I change it so that any post from the *user* that
>  has that email address is blocked? This way the user would be
>  prevented from posting via the Web, or we could also send the user a
>  notification by email. Bonus question: should we still block these
>  messages from unclosed groups?

Quite possibly it should be any post from a user who has that email
address is blocked. e-democracy use this feature to prevent users who
have been abusive from posting. It should definitely block these
messages from 'unclosed/open' groups too. (in that case the email
address check would still be very important).

I have finished the conversion and testing of the new Can the User Post code,
which I have been working on. I have come across some rather interesting
properties of GroupServer mailing lists that I had not seen before.

One is the ability to block messages from a particular email address.
Currently, if this happens, the message is dropped, without any notification.
Should I change it so that any post from the *user* that has that email address
is blocked? This way the user would be prevented from posting via the Web, or
we could also send the user a notification by email. Bonus question: should we
still block these messages from unclosed groups?

I am currently working on rewriting the code that determines if a person can
post to a group or not, and it turns out that my estimates of how many checks
are required were a little shy of the mark: there are eight checks, excluding
moderation, not six. The current list is as follows.

1. The first check is to see if the group restricts who can post. Support
   groups, for example, allow anyone to post.
2. If there are restrictions, check if the user is a member of the system. This
   requires people who post using the Web interface to log in first.
3. Check if the user is a member of the group.
4. Check if the user has valid email addresses (we do not want people without
   verified email addresses to post).
5. Check if the user is a posting member. Not all members of a group can post:
   announcement groups often restrict who can post.
6. Check if the posting limits been hit. This restricts "me too" posts
   clogging up the system. Participation coaches and (in the new code)
   administrators are not subject to this restriction.
7. Check if the user been specifically blocked from posting. There is no user
   interface for this, as moderation takes care of most of the use case for
   this feature.
8. Check if all the required user-properties for the site and the group have
   been set. The required properties for a site are set at a global level,
   while individual groups can require particular user-properties to be set.

I have finished work on the new invitation system, but as it is Friday I
will not update OnlineGroups.Net. In summary, it is no longer possible to
add a person to a group through the standard GroupServer interface.
Instead, the user is *invited* to join a group.

Invitations are sent to existing users (and existing users only) in the
following situations.
  * A user is explicitly invited to join the group using the new Invite
    User interface.
  * A user is explicitly invited to join the group using the updated
    Invite Site Members to Join a Group interface.
  * A user is added using the Add a New Member interface, but the email
    address already belongs to an existing user.
  * A user is added using the Add New Members in Bulk interface, but the
    email address already belongs to an existing user.

The invitation email message contains a single link. When the user clicks
on the link, he or she is logged in and taken to the Respond to
Invitations page, which lists all the current invitations for the user,
who made the invitation, and when. There the user can accept or decline
each invitation. The person who invited the user is sent a message stating
what the user did; if the user accepts the invitation the participation
coach for the group is sent a message stating that the user has joined the
group.

I also took the opportunity to enhance sign-up, so the participation coach
is informed when a person signs up and joins a group using the Web, and
when a new user responds to the invitation to join a group. The only time
a participation coach is *not* informed of a someone joining a group is
when someone subscribes by email.

(We would love it if you could configure who received the join-notification
messages, but it turns out to be a non-trivial problem, for now.)

As well as the Respond to Invitations page, I have the
  * Invite a User to Join Some Groups, and
  * Invite Site Members to Join a Group
sending out invitations, and the invitations correctly redirecting the user to
the Respond to Invitations page. The last three things to do are add some
restrictions, clean up the Invite Site Members page, and hook Add New Member
into the new system.

The only restriction that I will add, at this stage, is to limit the number of
invitations to a single group that can be sent to a single user without that
user responding. The other restrictions that I mentioned earlier
  http://groupserver.org/r/post/2CPcvdSFQrROAeK7XBUvgG
can be implemented, but I will not look at them until I need to.

The Invite Site Members page has no supporting text at the moment. I would also
like it if I could link to the users' profiles better. It should not take me
too long!

Finally, I the Add a New Member and Add New Members in Bulk pages need to be
hooked up to the new invitation system. (That was, in many ways, the entire
point of the exercise!)

Once those tasks are done, I will release the code on OGN, and build a new
tar-ball of GroupServer.

I have finished work on the initial Respond to Invitations page. The screenshot
below shows it in the OnlineGroups.Net livery. The main change from the
prototype is that every invitation says who created it, as I realised that a
user could have invitations from many different administrators. The Change
Group Email Settings section is also missing, but that is a nice-to-have
feature ☺

I am writing the interfaces backwards: from the end-user pages to the
administrator pages. The next page that I will write is the page to allow an
administrator to invite a single user to join multiple groups. It is very
useful for testing, so I would like it early. After that I will rewrite the
page that allows an administrator to invite multiple people to join a single
group.

Thanks for your comments, Steve. I am encourage to see that we are all
on the same page ☺ We have been thinking of the mechanism for preventing
people for being bombarded with invitations, as this is a privacy
breach. (Technically it is an invasion of privacy — but arguing privacy
semantics is dull at the best of times!) Exactly how the restrictions
will be presented is not something that I am very clear on, so I could
do with some guidance on that.

The way invitations-table is recording the invitation is with the
following fields:
      * invitation_id
      * user_id
      * inviting_user_id
      * site_id
      * group_id
      * invitation_date
      * response_date
      * accepted
When the invitation is sent out, we will write the first six fields.
When a user responds to the invitation we will write out the last two
fields: the date of the response, and if the user accepted the response
or not. This scheme allows us to restrict
      * How many invitations a user can have
      * How many invitations an administrator can send,
      * How many invitations for a group can be sent out
      * How many invitations for a *site* can be sent
      * How long before an invitation can be re-sent if a user has not
        responded
      * How long before an invitation can be re-sent if the user has
        declined.
By never deleting the invitations, I can implement all these
restrictions. In addition, I can also present a log of all invitations:
pending and past. (The log is what I am working on now.)

What the actual restrictions should be is something I will leave to the
configuration options. As you say, Steve, sites like the forums on
e-democracy.org will have quite different requirements to
OnlineGroups.Net.

The user not responding to an invitation does not tell you why the user
has not responded. We will need to work the bounce-detection into the
invitation subsystem to be able to give you any meaningful data.

From an hosts perspective it would be useful if you could put in a list of
e-mail addresses (one per line) or something.

However, for at least your OGN site I'd have a cap on the number of people you
can invite this way on any one day.

Also, I'd be interested in having an automatic reminder after one week or ten
days, "you didn't respond, if you don't with the next 2 days your invitation
will expire."

Also, when E-Democracy.Org launches a new forum we encourage people to recruit
elected officials quite heavily. Being able to quickly see who joined, who
declined, and who has not responded would be very useful. Also keeping a
listing
  of expired invites would help reduce repeat invitations (or at least
unintentional ones).

One concern I have is folks inviting people indiscriminately. Upon declining
...
"Thank you for your response. If you would like to share a comment on why you
are declining, please share it here/e-mail X"  This might create a feedback
loop
that would educate those using this feature.

Thanks,
Steven Clift

On Thu, 2008-06-26 at 14:06 +1200, Michael JasonSmith wrote:
> I just realised that when you subscribe to a group using email you are
effectively responding to your own invitation:
>   1. Send subscribe message,
>   2. GroupServer sends a confirmation message,
>   3. You respond.
> I see the potential to reduce code ☺

Definitely. I'm all for reducing code, but even better I think this
probably removes a template, and I'd definitely all for removing
anything Zope-side ...

I just realised that when you subscribe to a group using email you are
effectively responding to your own invitation:
  1. Send subscribe message,
  2. GroupServer sends a confirmation message,
  3. You respond.
I see the potential to reduce code ☺

Really nice, Michael. Thanks for thinking this through so thoroughly.

Dan