COmanage Developers List

[Marie Huynh <>]

On Wed, Jun 13, 2012 at 12:04 PM, Benn Oshrin <> wrote:

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.

Should it be tacked onto cm_co_enrollment_flows then?

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.

 

Yes, we can override the default.  It's as simple as:

          $email = new CakeEmail('default');

          $email->from('');

 

        > * 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

Did you forget to finish a thought here? :D 

        > * 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.

 

debug($somevar) does the check and only prints if level>0.  Did we make a decision about [not] committing debug statements a while back?

 

        > 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.

It looks like I'll be doing a bit of digging to do the refactoring so I'm going to split it into another ticket so I can focus on and finish the items above it.

Marie

 

-Benn-