Skip to Content.
Sympa Menu

comanage-dev - Re: [comanage-dev] Re: [JIRA] (CO-352) Implement Email Delivery

Subject: COmanage Developers List

List archive

Re: [comanage-dev] Re: [JIRA] (CO-352) Implement Email Delivery


Chronological Thread 
  • From: Benn Oshrin <>
  • To:
  • Subject: Re: [comanage-dev] Re: [JIRA] (CO-352) Implement Email Delivery
  • Date: Wed, 13 Jun 2012 15:04:52 -0400

On 6/13/12 1:57 AM, Marie Huynh wrote:
On Tue, Jun 12, 2012 at 7:51 PM, Scott Koranda
<

<mailto:>>
wrote:

> A few questions:
>
> * What should the default email address for all emails from
CoManage be?
>


<mailto:>?
This will
be set in the config file(email.php); I should
> update the installation instructions once that's figured out.

Can we ultimately configure this through the UI instead of through the installation mechanism? I can help figure out where it would need to be stored, but this might even be defined per-enrollment flow.

I'm assuming there's some facility for setting this dynamically when email is composed. The default value could then be left as something like '' or something like that, to indicate misconfiguration.

> * How do we want to internationalize the email messages? The
same lang file as
> we've been doing? This is potentially long and messy,
depending on how many
> email messages are to be sent from the system.

Do you have another proposal?

The cake book

(http://book.cakephp.org/2.0/en/core-libraries/internationalization-and-localization.html)
offers three options for internationalization, none of which we are
using right now. I am inclined to continue using the lang file for
consistency's sake for now and convert it completely to one of those
later, but I don't know when we'll get to it. I'm sure we have an
internationalization ticket floating around in jira somewhere though.

The ticket you're referencing is probably

https://bugs.internet2.edu/jira/browse/CO-351

Let's put off the redesign for the moment, which means sticking with the lang file approach. Let's keep the text short, on the assumption that people will want to change it anyway. For demo purposes it could be something like

> * What should be displayed on the sent page? It currently
says(based on
> send.ctp):
>
> Invitation for asdf Sent to asdf
> Email would be sent to


<mailto:>
with the URL
>
> http://localhost/gears/trunk/co_invites/reply/
> 54b7b18716e7ac036efb76bec2f32213d3636e9b
>
>
> I think it's good to keep the page so that there is
confirmation that the
> invitation was successfully sent. I'm thinking something like:
> Your invitation has been sent to <some name> at <some email>
with this URL this
> link for further action:
> http://wherever.com/co_invites/reply/hexhexhexhexhexhex

I would not include the URL--people will surely click on it
even though the invitation is not meant for them.

Good point. Should we even display it on the confirmation page then?

I agree with Scott. It was only on the confirmation page because email wasn't being sent.

You might consider checking for debug mode, and if in debug mode display the URL otherwise don't.

> As for refactoring send, the function is about 175 lines
long. Ugh. How much
> of that is really specific to the invitations and how much
can be reused
> elsewhere on the site? Does it make sense to refactor it out
of CoInvites?

Some refactor is in order, but a lot of it is handling that for the other controllers is handled in StandardController. There is, of course, no StandardController::send().

Lines 358-400 should probably be in the model, not the controller. Not sure about 313-340... I don't think there's too much of this that would be moved out of CoInvites (model or controller), this is all pretty specific. The actual send operation that is described but not executed on line 391 should almost certainly be called from the CoInvite model.

I can help with this refactor if you like. Or you can use CoPetitions as a template. Note specifically the use of try/catch for exception handling.

-Benn-



Archive powered by MHonArc 2.6.16.

Top of Page