22 Apr
2010
22 Apr
'10
10:16 p.m.
On 04/21/2010 11:37 AM, Caleb James DeLisle wrote:
This makes sense in the "allow registration only for invited people"
usecase, and the goal would be to correct wrongly sent invitations.
After all, if you want such a tight control over who has the right to
become a member, you wouldn't want a user to be allowed to register just
because some bozo couldn't type the right email address...
This could work by having an invitation ID, and if the invitation ID is
wrong or canceled, display a little warning about the fact that the
invitation is wrong, and the usual bla-bla: try copy-pasting, request
another invitation, or (if the registration is public) just proceed to
normal registration.
It could be done easily if we refactor the rights system to be more
modular. If we do this, then it would be easy to add another check for
registration which looks at the invitationID and checks if it is valid.
But right now it's almost impossible.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Ecaterina Valica wrote:
-0 on letting users change the Subject.
Also, when you hit the Preview, you actually see
that Subject and Message
fields have standard content. This content should be displayed from the
start and the user should have control over it.
I was thinking the mail should
give some explanation of why the email was sent, suppose the
user clears the default content and sets "buy cheap pharmaceuticals....." as
the entire content.
The mail recipient will have no way of knowing how the mail got to them or reporting it
as spam.
Anyway the default template is adjustable in the admin app so it's just a matter of
what it is by
default. >> Also,
is it possible to cancel an
>> invitation?
Somehow stop the email en route? Send another one saying
"just kidding"?
When the user comes to sign up say: "Nobody really likes you we were just
kidding."
Anyway the join button currently only redirects to the registration page and does
nothing special. >> How is
the invitation application going to work in a wiki where
>> registration is disabled? i.e. you have to be invited to be able to
>> register.
Another use case I didn't think of. Might require API
changes if registration is blocked
by setting register permission to deny. Also will cause some kind of dependency. I try
to resist dependencies lest every page depend on every other page and removal of one
causes
total destruction of the system. Still this sounds like a compelling use case. Maybe
this
should be implemented now or road mapped for later? Any thoughts?