On 15 November 2012 12:54, Peter Koželj <[email protected]> wrote: > > > On 8 November 2012 21:53, Olemis Lang <[email protected]> wrote: > >> On 11/6/12, Peter Koželj <[email protected]> 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: >> > >
