CONTINUUM-310 - customizable email templates

[stojcevicht]

This was marked closed, should it have been?  I still see no way of
allowing the user to customize the content of the email body.

Right now the velocity templates are part of the continuum-core
project and are buried inside the core.jar so it's not easy for the
users to edit the template.

What does everybody think about adding a step to the continuum-webapp
project that extracts the templates from the continuum-core.jar and
puts a copy of them in the WEB-INF/classes directory.  When the mail
notifier loads the templates it should find the ones in the
WEB-INF/classes before the ones in the jar and run with those.

That way the users can edit them and customize them any way they want.

--
tom

[Rahul Thakur-3]

I think this might be a good feature to have in continuum. Users can be
allowed to create their own notification templates that can be stored in
DB for a given build. In case of no email template, we use the default.

Thoughts?

Cheers,
Rahul


Tomislav Stojcevich wrote:

> This was marked closed, should it have been?  I still see no way of
> allowing the user to customize the content of the email body.
>
> Right now the velocity templates are part of the continuum-core
> project and are buried inside the core.jar so it's not easy for the
> users to edit the template.
>
> What does everybody think about adding a step to the continuum-webapp
> project that extracts the templates from the continuum-core.jar and
> puts a copy of them in the WEB-INF/classes directory.  When the mail
> notifier loads the templates it should find the ones in the
> WEB-INF/classes before the ones in the jar and run with those.
>
> That way the users can edit them and customize them any way they want.
>
>  

[Emmanuel Venisse]

I think the best way would be to allow the user to chosse his own template, if a template isn't define, continuum will choose the default.

About the issue, I closed it because the mail is customizable (subject, print or not the build output...) but if we can allow new templates, we'll can reopen this issue or open a new one.

Emmanuel

Rahul Thakur a écrit :

> I think this might be a good feature to have in continuum. Users can be
> allowed to create their own notification templates that can be stored in
> DB for a given build. In case of no email template, we use the default.
>
> Thoughts?
>
> Cheers,
> Rahul
>
>
> Tomislav Stojcevich wrote:
>> This was marked closed, should it have been?  I still see no way of
>> allowing the user to customize the content of the email body.
>>
>> Right now the velocity templates are part of the continuum-core
>> project and are buried inside the core.jar so it's not easy for the
>> users to edit the template.
>>
>> What does everybody think about adding a step to the continuum-webapp
>> project that extracts the templates from the continuum-core.jar and
>> puts a copy of them in the WEB-INF/classes directory.  When the mail
>> notifier loads the templates it should find the ones in the
>> WEB-INF/classes before the ones in the jar and run with those.
>>
>> That way the users can edit them and customize them any way they want.
>>
>>  
>
>
>

[stojcevicht]

I think it should be re-opened since there still is no way to
completely customize the template itself other than turning on and off
the output and summary.  In my case the turning on the summary wiith
the build output turned off will give me what I want but it is still
too much.  I'd like to be able to customize further, there are only a
couple of things from the summary that I want to see.  We could
continue to add flags to the xml file and if checks within the
template but where does it stop?

And what about internationalization? that would have to be a separate
issue but allowing access to be able to modify the templates directly
would at least let those users that really need to change the language
of the text that is hardcoded in the template to be able to do it
should they need to.

So how about my idea about extracting the templates from the core jar
into the webapp during the webapp build, that way they can be directly
modified?  This at least allows the default templates to be
customizable easily.


Another issue should be opened to provide the functionality that Rahul
is suggesting about allowing different templates per group or project.
 That would involve more changes.  There would have to be a place in
the database to store template location per project or group or
possibly store the template itself and provide a template edit screen.

[Emmanuel Venisse]

Tomislav Stojcevich a écrit :

> I think it should be re-opened since there still is no way to
> completely customize the template itself other than turning on and off
> the output and summary.  In my case the turning on the summary wiith
> the build output turned off will give me what I want but it is still
> too much.  I'd like to be able to customize further, there are only a
> couple of things from the summary that I want to see.  We could
> continue to add flags to the xml file and if checks within the
> template but where does it stop?
>
> And what about internationalization? that would have to be a separate
> issue but allowing access to be able to modify the templates directly
> would at least let those users that really need to change the language
> of the text that is hardcoded in the template to be able to do it
> should they need to.
>
> So how about my idea about extracting the templates from the core jar
> into the webapp during the webapp build, that way they can be directly
> modified?  This at least allows the default templates to be
> customizable easily.

I don't think it's the best solution. IMO, it would be better to allow the user to choose the template he want to use if he don't want the default.
>
>
> Another issue should be opened to provide the functionality that Rahul
> is suggesting about allowing different templates per group or project.
>  That would involve more changes.  There would have to be a place in
> the database to store template location per project or group or
> possibly store the template itself and provide a template edit screen.

If we allow to have a template per group or project, in fact per mail notifier, it's easy to add this feature if the one above is implemented. We can store it in the mail notifier configuration field
so we don't need to change the db schema for it.

Emmanuel

[Wendy Smoak-3]

On 10/1/07, Tomislav Stojcevich <stojcevicht@...> wrote:

> What does everybody think about adding a step to the continuum-webapp
> project that extracts the templates from the continuum-core.jar and
> puts a copy of them in the WEB-INF/classes directory.  When the mail
> notifier loads the templates it should find the ones in the
> WEB-INF/classes before the ones in the jar and run with those.
>
> That way the users can edit them and customize them any way they want.

I have an outstanding "make things pre-configurable" requirement.
Right now it's for the General Configuration that you're forced to
edit the first time the app starts, and it will apply to this as well.

So I need to be able to pre-configure 'what template to use' in an XML
file and also place the templates somewhere prior to starting the app
that they will be seen and used.

There is already continuum.xml file that I planned to use for the
general configuration, should I ever find time to work on that...

Thanks,
--
Wendy

[Rahul Thakur-3]

I agree with Emmanuel; extracting templates from core jar is not a solution.

So far from this thread it seems there are quite a few things we could
do for the email template customization feature. IMO, We need to
brainstorm what might make best sense.

Do we allow custom email templates for:
1) each Build Definition?
2) each  mail notifier defined?
3) each Project/Project Group?
and,
4) What is the order of precedence if there were custom templates
defined at different levels?

IMO, I think we should persist the notifiers in the database itself in a
separate field.

WDYT?

Rahul


Emmanuel Venisse wrote:

>
>
> Tomislav Stojcevich a écrit :
>> I think it should be re-opened since there still is no way to
>> completely customize the template itself other than turning on and off
>> the output and summary.  In my case the turning on the summary wiith
>> the build output turned off will give me what I want but it is still
>> too much.  I'd like to be able to customize further, there are only a
>> couple of things from the summary that I want to see.  We could
>> continue to add flags to the xml file and if checks within the
>> template but where does it stop?
>>
>> And what about internationalization? that would have to be a separate
>> issue but allowing access to be able to modify the templates directly
>> would at least let those users that really need to change the language
>> of the text that is hardcoded in the template to be able to do it
>> should they need to.
>>
>> So how about my idea about extracting the templates from the core jar
>> into the webapp during the webapp build, that way they can be directly
>> modified?  This at least allows the default templates to be
>> customizable easily.
>
> I don't think it's the best solution. IMO, it would be better to allow
> the user to choose the template he want to use if he don't want the
> default.
>>
>>
>> Another issue should be opened to provide the functionality that Rahul
>> is suggesting about allowing different templates per group or project.
>>  That would involve more changes.  There would have to be a place in
>> the database to store template location per project or group or
>> possibly store the template itself and provide a template edit screen.
>
> If we allow to have a template per group or project, in fact per mail
> notifier, it's easy to add this feature if the one above is
> implemented. We can store it in the mail notifier configuration field
> so we don't need to change the db schema for it.
>
> Emmanuel
>
>

[Rahul Thakur-3]

Wendy Smoak wrote:

> On 10/1/07, Tomislav Stojcevich <stojcevicht@...> wrote:
>
>  
>> What does everybody think about adding a step to the continuum-webapp
>> project that extracts the templates from the continuum-core.jar and
>> puts a copy of them in the WEB-INF/classes directory.  When the mail
>> notifier loads the templates it should find the ones in the
>> WEB-INF/classes before the ones in the jar and run with those.
>>
>> That way the users can edit them and customize them any way they want.
>>    
>
> I have an outstanding "make things pre-configurable" requirement.
> Right now it's for the General Configuration that you're forced to
> edit the first time the app starts, and it will apply to this as well.
>
> So I need to be able to pre-configure 'what template to use' in an XML
> file and also place the templates somewhere prior to starting the app
> that they will be seen and used.
>
> There is already continuum.xml file that I planned to use for the
> general configuration, should I ever find time to work on that...
>
> Thanks,
>  

Are you implying configuring custom email templates (rather path to
custom email template[s]) in continuum.xml?

Rahul

[jmcconnell]

I rather like the configuration of pebble where some of the configuration is
just putting in classnames and the same could easily be done with the vm
template resource location, source from some configuration and then if
resource isn't found just use the default like emm was saying...

jesse

On 10/2/07, Rahul Thakur <rahul.thakur.xdev2@...> wrote:

>
>
> I agree with Emmanuel; extracting templates from core jar is not a
> solution.
>
> So far from this thread it seems there are quite a few things we could
> do for the email template customization feature. IMO, We need to
> brainstorm what might make best sense.
>
> Do we allow custom email templates for:
> 1) each Build Definition?
> 2) each  mail notifier defined?
> 3) each Project/Project Group?
> and,
> 4) What is the order of precedence if there were custom templates
> defined at different levels?
>
> IMO, I think we should persist the notifiers in the database itself in a
> separate field.
>
> WDYT?
>
> Rahul
>
>
> Emmanuel Venisse wrote:
> >
> >
> > Tomislav Stojcevich a écrit :
> >> I think it should be re-opened since there still is no way to
> >> completely customize the template itself other than turning on and off
> >> the output and summary.  In my case the turning on the summary wiith
> >> the build output turned off will give me what I want but it is still
> >> too much.  I'd like to be able to customize further, there are only a
> >> couple of things from the summary that I want to see.  We could
> >> continue to add flags to the xml file and if checks within the
> >> template but where does it stop?
> >>
> >> And what about internationalization? that would have to be a separate
> >> issue but allowing access to be able to modify the templates directly
> >> would at least let those users that really need to change the language
> >> of the text that is hardcoded in the template to be able to do it
> >> should they need to.
> >>
> >> So how about my idea about extracting the templates from the core jar
> >> into the webapp during the webapp build, that way they can be directly
> >> modified?  This at least allows the default templates to be
> >> customizable easily.
> >
> > I don't think it's the best solution. IMO, it would be better to allow
> > the user to choose the template he want to use if he don't want the
> > default.
> >>
> >>
> >> Another issue should be opened to provide the functionality that Rahul
> >> is suggesting about allowing different templates per group or project.
> >>  That would involve more changes.  There would have to be a place in
> >> the database to store template location per project or group or
> >> possibly store the template itself and provide a template edit screen.
> >
> > If we allow to have a template per group or project, in fact per mail
> > notifier, it's easy to add this feature if the one above is
> > implemented. We can store it in the mail notifier configuration field
> > so we don't need to change the db schema for it.
> >
> > Emmanuel
> >
> >
>
>

--
jesse mcconnell
jesse.mcconnell@...

[Rahul Thakur-3]

I haven't seen pebble config...
I was thinking what if you move database between Continuum installs?
Since your template resides outside the db, it won't be portable.


Jesse McConnell wrote:

> I rather like the configuration of pebble where some of the configuration is
> just putting in classnames and the same could easily be done with the vm
> template resource location, source from some configuration and then if
> resource isn't found just use the default like emm was saying...
>
> jesse
>
> On 10/2/07, Rahul Thakur <rahul.thakur.xdev2@...> wrote:
>  
>> I agree with Emmanuel; extracting templates from core jar is not a
>> solution.
>>
>> So far from this thread it seems there are quite a few things we could
>> do for the email template customization feature. IMO, We need to
>> brainstorm what might make best sense.
>>
>> Do we allow custom email templates for:
>> 1) each Build Definition?
>> 2) each  mail notifier defined?
>> 3) each Project/Project Group?
>> and,
>> 4) What is the order of precedence if there were custom templates
>> defined at different levels?
>>
>> IMO, I think we should persist the notifiers in the database itself in a
>> separate field.
>>
>> WDYT?
>>
>> Rahul
>>
>>
>> Emmanuel Venisse wrote:
>>    
>>> Tomislav Stojcevich a écrit :
>>>      
>>>> I think it should be re-opened since there still is no way to
>>>> completely customize the template itself other than turning on and off
>>>> the output and summary.  In my case the turning on the summary wiith
>>>> the build output turned off will give me what I want but it is still
>>>> too much.  I'd like to be able to customize further, there are only a
>>>> couple of things from the summary that I want to see.  We could
>>>> continue to add flags to the xml file and if checks within the
>>>> template but where does it stop?
>>>>
>>>> And what about internationalization? that would have to be a separate
>>>> issue but allowing access to be able to modify the templates directly
>>>> would at least let those users that really need to change the language
>>>> of the text that is hardcoded in the template to be able to do it
>>>> should they need to.
>>>>
>>>> So how about my idea about extracting the templates from the core jar
>>>> into the webapp during the webapp build, that way they can be directly
>>>> modified?  This at least allows the default templates to be
>>>> customizable easily.
>>>>        
>>> I don't think it's the best solution. IMO, it would be better to allow
>>> the user to choose the template he want to use if he don't want the
>>> default.
>>>      
>>>> Another issue should be opened to provide the functionality that Rahul
>>>> is suggesting about allowing different templates per group or project.
>>>>  That would involve more changes.  There would have to be a place in
>>>> the database to store template location per project or group or
>>>> possibly store the template itself and provide a template edit screen.
>>>>        
>>> If we allow to have a template per group or project, in fact per mail
>>> notifier, it's easy to add this feature if the one above is
>>> implemented. We can store it in the mail notifier configuration field
>>> so we don't need to change the db schema for it.
>>>
>>> Emmanuel
>>>
>>>
>>>      
>>    
>
>
>  

[Emmanuel Venisse]

Wendy,

All continuum conf will be externalized in 1.2

Emmanuel

Wendy Smoak a écrit :

> On 10/1/07, Tomislav Stojcevich <stojcevicht@...> wrote:
>
>> What does everybody think about adding a step to the continuum-webapp
>> project that extracts the templates from the continuum-core.jar and
>> puts a copy of them in the WEB-INF/classes directory.  When the mail
>> notifier loads the templates it should find the ones in the
>> WEB-INF/classes before the ones in the jar and run with those.
>>
>> That way the users can edit them and customize them any way they want.
>
> I have an outstanding "make things pre-configurable" requirement.
> Right now it's for the General Configuration that you're forced to
> edit the first time the app starts, and it will apply to this as well.
>
> So I need to be able to pre-configure 'what template to use' in an XML
> file and also place the templates somewhere prior to starting the app
> that they will be seen and used.
>
> There is already continuum.xml file that I planned to use for the
> general configuration, should I ever find time to work on that...
>
> Thanks,

[Emmanuel Venisse]

We can't move all in the db because schema updates can be a pain.
In 1.2 all the conf, actually written in application.xml, will be move to an external file. This file will can be stored in ${user.home} so each installs will can use it like it is done in
archiva-configuration.

Emmanuel

Rahul Thakur a écrit :

>
> I haven't seen pebble config...
> I was thinking what if you move database between Continuum installs?
> Since your template resides outside the db, it won't be portable.
>
>
> Jesse McConnell wrote:
>> I rather like the configuration of pebble where some of the
>> configuration is
>> just putting in classnames and the same could easily be done with the vm
>> template resource location, source from some configuration and then if
>> resource isn't found just use the default like emm was saying...
>>
>> jesse
>>
>> On 10/2/07, Rahul Thakur <rahul.thakur.xdev2@...> wrote:
>>  
>>> I agree with Emmanuel; extracting templates from core jar is not a
>>> solution.
>>>
>>> So far from this thread it seems there are quite a few things we could
>>> do for the email template customization feature. IMO, We need to
>>> brainstorm what might make best sense.
>>>
>>> Do we allow custom email templates for:
>>> 1) each Build Definition?
>>> 2) each  mail notifier defined?
>>> 3) each Project/Project Group?
>>> and,
>>> 4) What is the order of precedence if there were custom templates
>>> defined at different levels?
>>>
>>> IMO, I think we should persist the notifiers in the database itself in a
>>> separate field.
>>>
>>> WDYT?
>>>
>>> Rahul
>>>
>>>
>>> Emmanuel Venisse wrote:
>>>    
>>>> Tomislav Stojcevich a écrit :
>>>>      
>>>>> I think it should be re-opened since there still is no way to
>>>>> completely customize the template itself other than turning on and off
>>>>> the output and summary.  In my case the turning on the summary wiith
>>>>> the build output turned off will give me what I want but it is still
>>>>> too much.  I'd like to be able to customize further, there are only a
>>>>> couple of things from the summary that I want to see.  We could
>>>>> continue to add flags to the xml file and if checks within the
>>>>> template but where does it stop?
>>>>>
>>>>> And what about internationalization? that would have to be a separate
>>>>> issue but allowing access to be able to modify the templates directly
>>>>> would at least let those users that really need to change the language
>>>>> of the text that is hardcoded in the template to be able to do it
>>>>> should they need to.
>>>>>
>>>>> So how about my idea about extracting the templates from the core jar
>>>>> into the webapp during the webapp build, that way they can be directly
>>>>> modified?  This at least allows the default templates to be
>>>>> customizable easily.
>>>>>        
>>>> I don't think it's the best solution. IMO, it would be better to allow
>>>> the user to choose the template he want to use if he don't want the
>>>> default.
>>>>      
>>>>> Another issue should be opened to provide the functionality that Rahul
>>>>> is suggesting about allowing different templates per group or project.
>>>>>  That would involve more changes.  There would have to be a place in
>>>>> the database to store template location per project or group or
>>>>> possibly store the template itself and provide a template edit screen.
>>>>>        
>>>> If we allow to have a template per group or project, in fact per mail
>>>> notifier, it's easy to add this feature if the one above is
>>>> implemented. We can store it in the mail notifier configuration field
>>>> so we don't need to change the db schema for it.
>>>>
>>>> Emmanuel
>>>>
>>>>
>>>>      
>>>    
>>
>>
>>  
>
>
>

[stojcevicht]

On 10/2/07, Rahul Thakur <rahul.thakur.xdev2@...> wrote:
>
> I agree with Emmanuel; extracting templates from core jar is not a solution.
>
yes, i do too but it was just a quick and dirty way to provide the
functionality without any major coding, I guess those users that want
it could still manually extract the templates and put them in the
classes dir after installing knowing that it might not be portable
between versions

[Wendy Smoak-3]

On 10/2/07, Emmanuel Venisse <emmanuel@...> wrote:
> We can't move all in the db because schema updates can be a pain.
> In 1.2 all the conf, actually written in application.xml, will be move to an external file. This file will can be stored in ${user.home} so each installs will can use it like it is done in
> archiva-configuration.

... or $CONTINUUM_HOME/conf, I assume?

Rahul, not sure if that was meant for me, but I'm not in favor of
putting either the configuration or the email templates in the
database.  Plain text rules. :)

Assuming they are loaded from the classpath, then the
path/package/filename goes in continuum.xml, and the files themselves
go somewhere that they end up on the classpath.

--
Wendy

[Wendy Smoak-3]

On 10/2/07, Tomislav Stojcevich <stojcevicht@...> wrote:
> On 10/2/07, Rahul Thakur <rahul.thakur.xdev2@...> wrote:
> >
> > I agree with Emmanuel; extracting templates from core jar is not a solution.
> >
> yes, i do too but it was just a quick and dirty way to provide the
> functionality without any major coding, I guess those users that want
> it could still manually extract the templates and put them in the
> classes dir after installing knowing that it might not be portable
> between versions

Sure, I'm doing that now at work to edit some of the JSP pages, and if
the email templates become a problem we'll "patch" those too after
installation.

Can you write up a page on the wiki explaining where things are and
how to do this?

http://docs.codehaus.org/display/CONTINUUMUSER/Home

Thanks,
--
Wendy

[Emmanuel Venisse]

Wendy Smoak a écrit :
> On 10/2/07, Emmanuel Venisse <emmanuel@...> wrote:
>> We can't move all in the db because schema updates can be a pain.
>> In 1.2 all the conf, actually written in application.xml, will be move to an external file. This file will can be stored in ${user.home} so each installs will can use it like it is done in
>> archiva-configuration.
>
> ... or $CONTINUUM_HOME/conf, I assume?

of course :)

>
> Rahul, not sure if that was meant for me, but I'm not in favor of
> putting either the configuration or the email templates in the
> database.  Plain text rules. :)
>
> Assuming they are loaded from the classpath, then the
> path/package/filename goes in continuum.xml, and the files themselves
> go somewhere that they end up on the classpath.
>

[olamy-2]

Hi,
File in ${user.home} can cause  trouble if you have two continuum instances
started with the same user/id and if you need different configurations
between instances.
But we can think about something which merge between $CONTINUUM_HOME/conf
and ${user.home) (I think plexus-registry can do this because it use
commons-configuration) with configuration in $CONTINUUM_HOME/conf  wins.
--
Olivier

2007/10/2, Emmanuel Venisse <emmanuel@...>:

>
>
>
> Wendy Smoak a écrit :
> > On 10/2/07, Emmanuel Venisse <emmanuel@...> wrote:
> >> We can't move all in the db because schema updates can be a pain.
> >> In 1.2 all the conf, actually written in application.xml, will be move
> to an external file. This file will can be stored in ${user.home} so each
> installs will can use it like it is done in
> >> archiva-configuration.
> >
> > ... or $CONTINUUM_HOME/conf, I assume?
>
> of course :)
>
> >
> > Rahul, not sure if that was meant for me, but I'm not in favor of
> > putting either the configuration or the email templates in the
> > database.  Plain text rules. :)
> >
> > Assuming they are loaded from the classpath, then the
> > path/package/filename goes in continuum.xml, and the files themselves
> > go somewhere that they end up on the classpath.
> >
>
>

--
Olivier

[stojcevicht]

>
> Can you write up a page on the wiki explaining where things are and
> how to do this?
>
> http://docs.codehaus.org/display/CONTINUUMUSER/Home
>
I would if it actually worked.  I just tried putting the templates in
the WEB-INF/classes (using the same fully qualified path that they
have in the core.jar) and made some changes.  My modified ones in
WEB-INF/classes are not getting picked up.

--
tom

[olamy-2]

Are you using plexus-runtime or tomcat ?
If it works with tomcat (adding the template in
WEB-INF/classes/${templatepath}).
It looks a classLoader issue with plexus-jetty because WEB-INF/classes must
wins against WEB-INF/lib.

--
Olivier

2007/10/2, Tomislav Stojcevich <stojcevicht@...>:

>
> >
> > Can you write up a page on the wiki explaining where things are and
> > how to do this?
> >
> > http://docs.codehaus.org/display/CONTINUUMUSER/Home
> >
> I would if it actually worked.  I just tried putting the templates in
> the WEB-INF/classes (using the same fully qualified path that they
> have in the core.jar) and made some changes.  My modified ones in
> WEB-INF/classes are not getting picked up.
>
> --
> tom
>

--
Olivier

[stojcevicht]

On 10/2/07, olivier lamy <olamy@...> wrote:
> Are you using plexus-runtime or tomcat ?
> If it works with tomcat (adding the template in
> WEB-INF/classes/${templatepath}).
> It looks a classLoader issue with plexus-jetty because WEB-INF/classes must
> wins against WEB-INF/lib.
using plexus