incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Whitelabeling: Notifications (Was: Re: White-labeling and "detracifying")
Date Mon, 19 Nov 2012 15:42:39 GMT
On 15 November 2012 12:54, Peter Koželj <peter@digiverse.si> wrote:

>
>
> On 8 November 2012 21:53, Olemis Lang <olemis@gmail.com> wrote:
>
>> On 11/6/12, Peter Koželj <peter@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:
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message