On 04/21/2010 11:37 AM, Caleb James DeLisle wrote:
Ecaterina Valica wrote:
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.
-0 on letting users change the Subject.
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.
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.
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?
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/