| Enhancement |
Added By |
Date |
Taken By |
Detail |
| Better subtab nav / better alert definition subtab view |
jshaughn |
Jun 09, 2010 |
|
jshaughn: the default alerts subtab is definitions. Would be nice if this list view gave some indication of alerts generated for the listed defs. today you have to click again and go to the history subtab to see if anything actually happened. maybe not a big deal given that alert notification is probably the primary mechanism for knowing if something happened
joseph: would be nice if users could hover over the alerts main-tab, and the sub-tabs would be auto-visible options to choose from before clicking
ips: jshaughn: +1. in addition to having an Alerts (Count) colun, we could potentially also add a Last Fired column with a dateTime
jshaughn: both of those would be nice
jshaughn: i like the subtab hover a lot, i hate having that multi-step process to get where I'm going
jshaughn: would be very useful for Inventory tab as well
joseph: yeah, preview functionality is not only bad ass, but often times actually useful too ; ) |
| Finish group-wise content functionality |
joseph |
June 22, 2010 |
|
Push this EAR out to that cluster; update (in rolling fashion) this clustered WAR |
| Availability lag |
jshaughn |
June 24, 2010 |
|
users don't necessarily understand why it takes so long to see whether a resource is up/down. |
| Availability alerting |
jshaughn |
June 24, 2010 |
|
not exactly or not all of what users expect (i.e. down and has been down for 10 minutes) |
| consistent perms |
in-office meeting |
sept 14, 2010 |
|
consistent write/read perms for all subsystems, i.e. CONTROL becomes OPERATION_READ and OPERATION_WRITE, just like CONFIGURE became CONFIGURE_READ and CONFIGURE_WRITE |
| authorization fixes |
in-office meeting |
sept 14, 2010 |
|
conditionally render tabs or disable/lock tabs? conditionally render buttons or disable/lock buttons? |
| resource "actions" |
in-office meeting |
sept 14, 2010 |
|
either right-hand side panel (collapsable) vs. pop-up menu somewhere on the content area vs. quick action icon (next to avail check and favorite badge) |
| in-line dashboard |
in-office meeting |
sept 14, 2010 |
|
integrate dashboard into resource/group details views - allows all named dashboards to be seen all the time, which facilities adding graphs in the current view to a specific named dashboard; also allows quick switching back and forth between |
| everything's a portlet |
in-office meeting |
sept 14, 2010 |
|
make everything a porlet for easier consumption via dashboards, e.g. recent ops for resource/group, recent config changes for resource/group, etc |
| ajax feedback mechanism |
in-office meeting |
sept 14, 2010 |
|
add an "in progress" spinner to all pages when gwt is doing something async - this might be done at the global level for all pages if there are any async things happening, or perhaps it should be relevant to the content area that is doing the async work. |
| event>source sub-tab |
in-office meeting |
sept 14, 2010 |
|
move event sources out of plugin config into event>configure sub-tab to sit alongside event>history sub-tab - this will also allow event source reconfiguration without having to restart the agent-side resource component, and allow for a more directed/concise UI for group-wise updates of just the event logging stuff |
| search trees |
in-office meeting |
sept 14, 2010 |
|
searchable resource / group trees - a tree showing search results might be a flattened but disambiguated result list, or it might be greyed inner tree nodes |
| precompute resource disambiguation |
in-office meeting |
sept 14, 2010 |
|
pre-compute resource disambiguation / lineage / hierarchy - the read/write profile is heavily weighted towards the read-access since nearly all fragments of all pages across the site need to be disambiguated. this would also enable us to easily expose lineage data via the remote API, instead of disambiguation being a UI-only thing |
| maven build forking |
in-office meeting |
sept 14, 2010 |
|
fix maven build to fork javac for most (all?) modules, this will lower the maximum memory requirement (Xmx) when building from scratch, as well as lower the needed memory when building individual modules (the common case) |
| alert notification bucketing |
in-office meeting |
sept 14, 2010 |
|
instead of getting alert notification storms, allow the user to configure when he/she should get notifications; so the system will queue up notifications and then send, in a single email, all queued notifications every 10 minutes for that user |
| true group alerting |
in-office meeting |
sept 14, 2010 |
|
e.g. "3 of 5 resources are down" or "the average heap usage is <yadda>" |
| composite alerting |
in-office meeting |
sept 14, 2010 |
|
instead of an alert definition being tied to a single resource or a single group or a single type (alert template), allow each alert condition to be related to a resource / group. this way you can say "if average web server group metric is <foo>" or "if average app server service metric is <bar>" or "if database metric is "yadda" then alert |
| complex alerting |
in-office meeting |
sept 14, 2010 |
|
more flexible alert condition processing - today we only support 'AND' vs 'OR' - let's support complex conditions such as (a AND (b OR c)) |
| parameterized web context |
ips / joseph |
sept 15, 2010 |
|
make coregui web context a configurable parameter as part of the build (<address>:7080/<context>/) so that we can have, for example, "/rhq" or "/jon" |
| in-line call-time instructions |
joseph |
sept 24, 2010 |
|
instead of forcing users to go to our documentation to figure out how to instrument their WARs for call-time data collection, make the web.xml snippet and instructions available in the monitor>response sub-tab itself. this way users go there, realize they haven't instrumented their app, and can easily copy/paste into their application's web.xml |
| in-line call-time enablement |
joseph |
sept 24, 2010 |
|
instead of forcing the users to go monitor>schedules to enable call-time data on the server-side for a resource (or group) enable them to click a quick link within the monitor>response tab which will enable the appropriate schedule automatically...or, at the very least, provide a link that takes them to monitor>schedules with instructions on what to do (this means that we should always keep the monitor>response sub-tab enables for resources that support it) |
| in-line call-time setup |
joseph |
sept 24, 2010 |
|
instead of forcing users to go to inventory>connection, allow viewing and alteration of the response time properties (log file, url excludes, url transforms) in line with the tabular results |
| in-line event source setup |
joseph |
sept 24, 2010 |
|
instead of forcing users to go to inventory>connection, move the creation to a new sub-tab called event>sources (or even in-line the viewing/editing of event sources at the top of the audit trail / table |