continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <>
Subject Re: CONTINUUM-310 - customizable email templates
Date Tue, 02 Oct 2007 14:38:24 GMT
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


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

View raw message