kaleo is really an extension on top of DUA signup codes that is just providing all the user level functionality so I think it is completely useful and not at all duplication to have an admin level invite thing in DUA.
As far as sending the email, I am ok with either. kaleo sends the email because it is creating the signup_code directly and calling send(), though I guess technically means DUA is sending it and kaleo is just calling a function in DUA that sends it. The hooksets that Brian added recently gives the site developer really full control over email if it needs to be customized at the site level (like routing through something like Mandrill or sending HTML emails, etc.). So I guess I am leaning towards keeping the emails sent from DUA and replicating the hookset functionality in other apps that send emails. On Tue, Jan 14, 2014 at 11:48 AM, James Tauber <[email protected]> wrote: > Given DUA has SignupCodes, it seems reasonable that a very simple way of > an admin generating a signup code would be available in DUA. > > Certainly once you get to a point where arbitrary users can invite others > to a site, or to a particular object on a site, etc: that shouldn't be done > in DUA but, rather, something like kaleo. > > The only item that is borderline for me is whether DUA should *send* an > email with the invitation. Right this minute I'm leaning towards no but I'm > interested in discussing that further. > > James > > > > On Wed, Jan 15, 2014 at 1:33 AM, Brian Rosner <[email protected]> wrote: > >> During my efforts of going through the big backlog of issues on >> django-user-accounts, I came across this issue: >> >> https://github.com/pinax/django-user-accounts/pull/98 >> >> It looks to add support for inviting users through SignupCode which we >> already support. The issue cities the old admin_invite_user view included >> with Pinax. >> >> I am trying to understand the split between kaleo and doing something in >> d-u-a. The original view we shipped with Pinax only allowed users with >> staff access to send invitations. However, I am sure there are a ton of >> different business-level requirements a user might want to implement. >> >> Do I include something or defer this through documentation? I think if we >> did something it would involve using a permission that would allow the site >> developer to control the logic of who can or cannot invite users with a >> SignupCode. >> >> Thoughts? >> >> -- >> Brian Rosner >> http://twitter.com/brosner >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Pinax Core Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/pinax-core-dev. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > James Tauber > http://jtauber.com/ > @jtauber on Twitter > > -- > You received this message because you are subscribed to the Google Groups > "Pinax Core Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pinax-core-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Patrick Altman Nashville, TN http://paltman.com -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pinax-core-dev. For more options, visit https://groups.google.com/groups/opt_out.
