Whitelabeling: Notifications (Was: Re: White-labeling and "detracifying")

[Peter Koželj <pe...@digiverse.si>]

On 8 November 2012 21:53, Olemis Lang <ol...@gmail.com> wrote:

> On 11/6/12, Peter Koželj <pe...@digiverse.si> wrote:
> > Hi,
> >
>
> :)
>
> > I would need to add some white-labeling support to Bloodhound. At the
> same
> > time I would also use the feature to change or remove some of the Trac
> > references throughout the application. The credits to the Trac and
> relation
> > description between Bloodhound and Trac needs to stay but there are
> > numerous points where Trac references serve no real purpose but to
> > potentially confuse new users. So this is I plan of what I intend to do
> or
> > is at least worth discussing:
> >
> > 1. Add ability to rename Bloodhound label in ui by changing configuration
> > file (white-labeling equivalent of i18n file) This same configuration
> would
> > be used for replacing Trac references where we would see fit. Personally
> I
> > would only leave the reference to Trac in Apps/About Bloodhound
> >
>
> Why not just sections in trac.ini itself rather than a separate file ?
> Having many config files/sources will make things a bit difficult ...
> afaics . In the end there should always a way to make such configs fit
> into INI file structure .
>
> > 2. Use the configuration for labeling in generated content (email
> > notifications) configurable
> >
>
> What are the options available now to get similar things done ?
>

So, thinking about this again and looking into the Trac notification
configuration there is not much added value to bring in whitelabaling for
this.

The only thing that could be done is to replace the Trac mail headers with
BH (whitelabeld) ones, but this
would again change the Trac code in a way that we will not be able to push
back to Trac project.

I will open a Ticket so we do not forget about it, but would only consider
executing it if (when) we start treating Trac code with patches instead of
full source repo with manual merging.


>
> > 3. Make footer text configurable by the same configuration file
> >
>
> This is possible already by editing trac.ini
>
> [project]
> footer = Lucy in the Sky with Diamonds
>
> afaicr installer script customizes the footer in default installations
> , but /me not sure .
>
> > 4. Trac version is referenced on all pages, as already said it should be
> > removed or moved to About page. Code wise references to Trac version
> happen
> > on multiple places, sometimes to hardcoded Trac version sometiemes to a
> > “calculated” one. We need to fix that.
> >
>
> We need to handle this in a consistent manner . Could you please
> mention examples ?
>
> > 5. Various readme files reference Trac as dependencies. This should be
> > examined more closely. Given that forked Trac version is bundled with BH
> it
> > seems that any dependencies on Trac as external project are not only
> > unnecessary but actually wrong! There is no white labeling features
> planned
> > for this
>
> I thought we were already stating that we distribute a custom copy of
> Trac , with references to the exact Trac version (relative to svn
> repos) incorporated into vendor branch .
>
> > 6. Plugins Kindly ask all plugin authors to take advantage of the new
> > white-labeling configuration file if it exists, offer white-labling
> feature
> > back to Trac.
> >
>
> IMO that request should be addressed to end users ... but maybe I'm
> missing something .
>
> > 7. Documentation (wiki) is full of Trac references,
>
> Yes , Trac-devs did the whole thing
> ;)
>
> > pages themselves
> > contain "Trac" in there name and in addition to that many of the links
> > contain "Trac" in text as well. And all of this very inconsistent
> applied.
> >
>
> We envisioned to migrate default wiki pages onto Guide/ folder (see #85)
>
> > But there is an even bigger issue with documentation. With BH gaining new
> > features the Trac documentation will be less and less relevant and may
> even
> > become misleading at some point.
>
> If we will evolve together with Trac then for a reasonable time a
> relevant % of the Trac guide will be valid .
>
> > I would at least remove "Trac" in links
> > until Trac documentation is replaced by Bloodhound documentation
> >
> > We could also remove "Trac" from the wiki page names. In fact there is
> some
> > code in bloodhound_dashboard/bhdashboard/admin.py
> > that implies that somebody was already thinking along that lines. Can
> > someone elaborate?
>
> #85 ;)
>
> > 8. Some of the Trac references appear in the names of the tools and
> > programming constructs of the Trac itself.
> >    These do not need to be white-labeled but it would be nice if we could
> > rename them more neutrally. This include:
> >
> >   o TRAC_ADMIN premission
>
> Hard to modify as references to this permission name are scattered all
> over trac and plugins code .
>
> >   o trac-admin CLI command
> >   o cleartracd CLI command
>
> yep
>
> >   o error handling: TracError is displayed in error report that user sees
> >
>
> This one could be «solved» by adding in trac.core something like
>
> {{{
> #!py
>
> class NewNameError(Exception):
>     ... TracError code
>
> TracError = NewNameError
>
> }}}
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

Re: Whitelabeling: Notifications (Was: Re: White-labeling and "detracifying")

[Ryan Ollos <ry...@wandisco.com>]

On Thu, Nov 15, 2012 at 3:54 AM, Peter Koželj <pe...@digiverse.si> wrote:

> [...]
> > > 2. Use the configuration for labeling in generated content (email
> > > notifications) configurable
> > >
> >
> > What are the options available now to get similar things done ?
> >
>
> So, thinking about this again and looking into the Trac notification
> configuration there is not much added value to bring in whitelabaling for
> this.
>
> The only thing that could be done is to replace the Trac mail headers with
> BH (whitelabeld) ones, but this
> would again change the Trac code in a way that we will not be able to push
> back to Trac project.
>
> I will open a Ticket so we do not forget about it, but would only consider
> executing it if (when) we start treating Trac code with patches instead of
> full source repo with manual merging.
>

The other possibility is to try to add the whitelabeling support you need
to the AnnouncerPlugin (1), which I've been involved in developing and
could help with. There is a long standing proposal to integrate
AnnouncerPlugin into the Trac core, which has led to almost no movement on
further developing the Trac notification system, and patches such as the
one I tried to push earlier this week (2) typically don't get integrated.
However, discussion on integrating the AnnouncerPlugin has picked up again
(3), so it may get integrated to the Trac core in an upcoming release, and
it may be easier to get the whitelabeling support added before integration.

That said, I don't really understand how Trac or the AnnouncerPlugin would
need to be changed to support whitelabeling, so some specifics might help
me with that.

(1) http://trac-hacks.org/wiki/AnnouncerPlugin
(2) http://trac.edgewall.org/ticket/2311
(3)
https://groups.google.com/forum/?fromgroups=#!topic/trac-users/zx2CeI4bJ40

Re: Whitelabeling: Notifications (Was: Re: White-labeling and "detracifying")

[Peter Koželj <pe...@digiverse.si>]

On 15 November 2012 12:54, Peter Koželj <pe...@digiverse.si> wrote:

>
>
> On 8 November 2012 21:53, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 11/6/12, Peter Koželj <pe...@digiverse.si> wrote:
>> > Hi,
>> >
>>
>> :)
>>
>> > I would need to add some white-labeling support to Bloodhound. At the
>> same
>> > time I would also use the feature to change or remove some of the Trac
>> > references throughout the application. The credits to the Trac and
>> relation
>> > description between Bloodhound and Trac needs to stay but there are
>> > numerous points where Trac references serve no real purpose but to
>> > potentially confuse new users. So this is I plan of what I intend to do
>> or
>> > is at least worth discussing:
>> >
>> > 1. Add ability to rename Bloodhound label in ui by changing
>> configuration
>> > file (white-labeling equivalent of i18n file) This same configuration
>> would
>> > be used for replacing Trac references where we would see fit.
>> Personally I
>> > would only leave the reference to Trac in Apps/About Bloodhound
>> >
>>
>> Why not just sections in trac.ini itself rather than a separate file ?
>> Having many config files/sources will make things a bit difficult ...
>> afaics . In the end there should always a way to make such configs fit
>> into INI file structure .
>>
>> > 2. Use the configuration for labeling in generated content (email
>> > notifications) configurable
>> >
>>
>> What are the options available now to get similar things done ?
>>
>
> So, thinking about this again and looking into the Trac notification
> configuration there is not much added value to bring in whitelabaling for
> this.
>
> The only thing that could be done is to replace the Trac mail headers with
> BH (whitelabeld) ones, but this
> would again change the Trac code in a way that we will not be able to push
> back to Trac project.
>
> I will open a Ticket so we do not forget about it, but would only consider
> executing it if (when) we start treating Trac code with patches instead of
> full source repo with manual merging.
>

Opened as: https://issues.apache.org/bloodhound/ticket/261


>
>
>>
>> > 3. Make footer text configurable by the same configuration file
>> >
>>
>> This is possible already by editing trac.ini
>>
>> [project]
>> footer = Lucy in the Sky with Diamonds
>>
>> afaicr installer script customizes the footer in default installations
>> , but /me not sure .
>>
>> > 4. Trac version is referenced on all pages, as already said it should be
>> > removed or moved to About page. Code wise references to Trac version
>> happen
>> > on multiple places, sometimes to hardcoded Trac version sometiemes to a
>> > “calculated” one. We need to fix that.
>> >
>>
>> We need to handle this in a consistent manner . Could you please
>> mention examples ?
>>
>> > 5. Various readme files reference Trac as dependencies. This should be
>> > examined more closely. Given that forked Trac version is bundled with
>> BH it
>> > seems that any dependencies on Trac as external project are not only
>> > unnecessary but actually wrong! There is no white labeling features
>> planned
>> > for this
>>
>> I thought we were already stating that we distribute a custom copy of
>> Trac , with references to the exact Trac version (relative to svn
>> repos) incorporated into vendor branch .
>>
>> > 6. Plugins Kindly ask all plugin authors to take advantage of the new
>> > white-labeling configuration file if it exists, offer white-labling
>> feature
>> > back to Trac.
>> >
>>
>> IMO that request should be addressed to end users ... but maybe I'm
>> missing something .
>>
>> > 7. Documentation (wiki) is full of Trac references,
>>
>> Yes , Trac-devs did the whole thing
>> ;)
>>
>> > pages themselves
>> > contain "Trac" in there name and in addition to that many of the links
>> > contain "Trac" in text as well. And all of this very inconsistent
>> applied.
>> >
>>
>> We envisioned to migrate default wiki pages onto Guide/ folder (see #85)
>>
>> > But there is an even bigger issue with documentation. With BH gaining
>> new
>> > features the Trac documentation will be less and less relevant and may
>> even
>> > become misleading at some point.
>>
>> If we will evolve together with Trac then for a reasonable time a
>> relevant % of the Trac guide will be valid .
>>
>> > I would at least remove "Trac" in links
>> > until Trac documentation is replaced by Bloodhound documentation
>> >
>> > We could also remove "Trac" from the wiki page names. In fact there is
>> some
>> > code in bloodhound_dashboard/bhdashboard/admin.py
>> > that implies that somebody was already thinking along that lines. Can
>> > someone elaborate?
>>
>> #85 ;)
>>
>> > 8. Some of the Trac references appear in the names of the tools and
>> > programming constructs of the Trac itself.
>> >    These do not need to be white-labeled but it would be nice if we
>> could
>> > rename them more neutrally. This include:
>> >
>> >   o TRAC_ADMIN premission
>>
>> Hard to modify as references to this permission name are scattered all
>> over trac and plugins code .
>>
>> >   o trac-admin CLI command
>> >   o cleartracd CLI command
>>
>> yep
>>
>> >   o error handling: TracError is displayed in error report that user
>> sees
>> >
>>
>> This one could be «solved» by adding in trac.core something like
>>
>> {{{
>> #!py
>>
>> class NewNameError(Exception):
>>     ... TracError code
>>
>> TracError = NewNameError
>>
>> }}}
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
>>
>
>