incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #140: User-defined dashboard contents.
Date Tue, 24 Jul 2012 03:38:08 GMT
#140: User-defined dashboard contents.
-------------------------+-------------------------------------------------
  Reporter:  olemis      |      Owner:  nobody
      Type:              |     Status:  new
  enhancement            |  Milestone:
  Priority:  minor       |    Version:
 Component:  dashboard   |   Keywords:  dashboard configuration database
Resolution:              |  markup preferences admin
-------------------------+-------------------------------------------------

Comment (by olemis):

 Replying to [comment:5 gjm]:
 > Replying to [comment:4 olemis]:
 > > Besides please consider reading [http://mail-
 archives.apache.org/mod_mbox/incubator-bloodhound-dev/201207.mbox
 /%3cCAGMZAuOB-rZ9+UMFGD7KRG-wn+1ea-_W5X2LTOeNh7Ch5rvJHg@mail.gmail.com%3e
 this message] actually started by Gary and related to role-specific (e.g.
 user groups) dashboards and other similar use cases , IMO requiring extra
 flexibility.
 >
 > I'm afraid that I am not convinced by this argument. Putting all the
 functionality into the single dashboard view was not what I was
 advocating.

 I'll clarify something here . My suggestion does not consist in including
 widgets in a single for developers, team leaders, ... any other role , in
 order to satisfy any possible expectations . No. My suggestion is to have
 a single ''URL'' to access dashboard and make it look like a home page.
 Nonetheless view should be able to adapt according to user decisions on
 what's important for him regarding products and associated resources.

 > In the long run it may be seen as worthwhile to provide this flexibility

 good

 > but my suggestion was to provide different standard views.

 as long as they'll be accessible at a single URL this doesn't conflict
 with my previous suggestion because ...

 > Part of the advantage of this would be that a user should not need to
 discover or build the most appropriate dashboard for themselves yet.
 > We can provide more standard views that everyone (or at least everyone
 with appropriate permissions) can view.
 >

 ... if the infrastructure for custom dashboard contents is somewhere then
 we can give the option (admin and|or preferences panel) for users to
 select between a set of built-in dashboards provided by the project and
 designed for particular use cases . That'd be fine in first place . Maybe
 later a separate plugin might extend these capabilities in order to let
 them design all the details at will, select widgets one-by-one, etc ...
 Nonetheless in any case we'll need customized dashboards and a mechanism
 to select what are the contents of interest for a particular user .

 You can see it this way too . It'll be possible to have multiple
 dashboards delivered by the project or plugins e.g. /dashboard/ticket ,
 /dashboard/team , /dashboard/vcs , ... but users will be able to see them
 listed in a form (admin or preferences panel) and select the one they'll
 see by default on accessing /dashboard path .

 > I think it would be better to shelve this discussion until a point at
 which we are ready to consider further generalisation of the dashboard. It
 is not that it is completely undesirable but there are more important
 things to get on with.

 We shall keep this ticket unscheduled until it will be the right time to
 start working on it .

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/140#comment:6>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

Mime
View raw message