#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-_w5x2ltoenh7ch5rv...@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
