Both product list and global dashboard currently require PRODUCT_VIEW permission in global context and are therefore not visible to anonymous users.
Are there any unwanted consequences if we grant this permission to all users (in global env) during the upgrade? Anze On Tue, Apr 30, 2013 at 10:38 AM, Joachim Dreimann <[email protected]> wrote: > On 29 April 2013 18:18, Olemis Lang <[email protected]> wrote: > >> Hi ! >> >> On 4/29/13, Joachim Dreimann <[email protected]> wrote: >> > On 29 April 2013 12:57, Gary Martin <[email protected]> wrote: >> >> On 29/04/13 11:42, Anze Staric wrote: >> >> >> >>> Upgrading wikis to multiproduct now moves all wikis (and attachments) >> >>> to default product. As a result, the main page ('/') is blank, as the >> >>> page WikiStart does not exist in the global product. >> >>> >> >>> If a user plans to create multiple products, this is not a big >> >>> problem, as he will probably need a new entry page anyway. We could >> >>> add one of the guides as a WikiStart page in global env to avoid >> >>> PageNotFound error. >> >>> >> >>> But if a user does not need multiple products (he just upgraded to >> >>> bloodhound because of our other awesome features), how should he >> >>> proceed? Should we provide a way to enable mapping of wikis in default >> >>> product to global namespace (the way we do with tickets, reports, >> >>> ...)? Or should such users just disable the multiproduct module in >> >>> trac.ini? >> >> >> [...] >> >> >> >> We could suggest that if an installation is only ever expected to be a >> >> single product installation then webserver configuration could be used >> to >> >> hide the global level. I think that a proper installation should include >> >> a >> >> webserver rather than using tracd directly. It might be possible to >> offer >> >> the opportunity to have non-multiproduct version if this decision is >> made >> >> early in the installation procedure as it may be more difficult to >> switch >> >> away later. If we were to support this then we would need more testing >> to >> >> be put in place of course to cover that possibility. >> >> >> > >> >> Notice that the global home page belongs to a given (global) >> environment . So `[trac]` `default_handler` config option will be >> handy . We could set that to `products` in global scope . >> >> > I don't believe we should provide a 'single product only' installation >> > option, if that's your suggestion. More complication for little gain. >> >> IMO this comment is influenced by a «developer» perspective . IMHO >> from a user perspective , things should be as backwards compatible as >> possible . For instance , via trac-users we have received requests for >> porting Bloodhound Search and Dashboard plugins to work on top of Trac >> core ... without multi-product >> >> > Users >> > that are so opposed to potentially using multiple products in future that >> > they want to decide at the point of installation to not use them should >> use >> > Trac instead. >> > >> >> ... maybe that's a valid approach . >> >> > >> >> Meanwhile, I think putting in a new WikiStart page for the global >> >> frontpage would be pretty reasonable. We might consider listing the >> >> products on that page in some way along with any other default text we >> >> want >> >> to provide. >> >> >> > >> > I think we should serve up the dashboard page as a landing page by >> default. >> >> IMHO one of the following options : >> >> 1. user dashboard aggregating and summarizing user >> activity across products would be ok e.g. similar to Bitbucket's . >> 2. products list >> > > I'm not familiar with Bitbucket's view, but option one is what the > Dashboard is intended to do. It includes a products list already (visible > when more than one product exists). > > >> >> > That page does need to be improved further to help facilitate the setup >> in >> > a new installation, but that's another topic and shouldn't stop us from >> > using it as the default landing page (global frontpage as Gary called >> it). >> > >> >> in case we choose (2) via `default_handler` it'll work ootb . >> ;) >> >> -- >> Regards, >> >> Olemis. >> >> Apache™ Bloodhound contributor >> http://issues.apache.org/bloodhound >> >> Blog ES: http://simelo-es.blogspot.com/ >> Blog EN: http://simelo-en.blogspot.com/ >> >> Featured article: >> > > > > -- > Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/> > > @jdreimann <https://twitter.com/jdreimann> > * > * > *Join one of our free daily demo sessions on* *Scaling Subversion for the > Enterprise <http://www.wandisco.com/training/webinars>* > > THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE > PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its > subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. > If you are not the intended recipient, please notify us immediately and > destroy the message without disclosing its contents to anyone. Any > distribution, use or copying of this e-mail or the information it contains > by other than an intended recipient is unauthorized. The views and > opinions expressed in this e-mail message are the author's own and may not > reflect the views and opinions of WANdisco, unless the author is authorized > by WANdisco to express such views or opinions on its behalf. All email > sent to or from this address is subject to electronic storage and review by > WANdisco. Although WANdisco operates anti-virus programs, it does not > accept responsibility for any damage whatsoever caused by viruses being > passed.
