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 Whitelabeling: Notifications (Was: Re: White-labeling and "detracifying")
Date Thu, 15 Nov 2012 11:54:40 GMT
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.


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