continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Thakur <rahul.thakur.xd...@gmail.com>
Subject Re: CONTINUUM-310 - customizable email templates
Date Tue, 02 Oct 2007 14:18:15 GMT

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@gmail.com> 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
>>>
>>>
>>>       
>>     
>
>
>   


Mime
View raw message