The `Get` method on the UsersStore was generalize by changing the second
parameter to a struct. This allows the Store to retrieve users by more
than simply their name.
-Get(ctx context.Context, name string) (*User, error)
+Get(ctx context.Context, q UserQuery) (*User, error)
Move source Users code into source_users and source_users_test files.
Use the UsersStore for both InfluxDB and Chronograf users.
Signed-off-by: Michael de Sa <mjdesa@gmail.com>
We would like to add additional user-configurable options to the display
of axes on Dashboards. This adds three fields to expand settings that
the frontend can persist through the API.
One field of interest here is the "Base" field which controls when and
how axes transition the display of values such as bytes, kilobytes,
megabytes, etc. By default, it's returned from the API as "10" to
indicate decimal, but can be set to anything the frontend wishes--the
immediate differing value will be "2" for the aforementioned use case.
The UI for selecting time ranges produces nanosecond-precision times
for the template variables in the absolute time range. The regex for
absolute time ranges previously did not account for this precision,
which caused it to break.
This updates the regex to consider the nanosecond parts of an
RFC3339Nano timestamp and updates the associated tests. The Gobular link
has also been updated to a fresh playground used to debug this issue.
This allows a creator of a layout to specify the visible extents of
graphs for individual cells. For example, a cell displaying a
percentage could be limited to values between 0 and 100.
Existing canned layouts need to updated as a separate step. However,
this adds support for Axes to appear in them as well.
Previously, users of the :interval: macro were restricted to using a
relative time range in their queries, or the :dashboardTime: macro. This
permits users to also supply an absolute time range in the form of:
time > '2017-01-01T00:00:00Z' and time < '2017-06-01T00:00:00Z'
Also removed LegacyBounds marshaling since it was no longer necessary
Conflicts resolved:
bolt/internal/internal.go
bolt/internal/internal.pb.go
bolt/internal/internal.proto
bolt/internal/internal_test.go
chronograf.go
server/cells_test.go
server/dashboards_test.go
server/swagger.json
Due to various limitations with the previous implementation of Bounds as
a [2]int64{}, we've decided to change this to a []string{}. This will
allow clients to store arbitrary data specifying a bound and interpret
it as they wish.
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
"Axis" is a more consistent and appropriate name. Also, the formatting
the protobufs was all over the place, so this has been made consistent
using a first-column \t. Furthermore, a vim modeline was added to the
bottom to make it easier for editors to autoconfigure themselves to the
right format, since protobufs are not something that we edit everyday.
Also, 32-bit values have been substituted for 64-bit values in Protobuf
definitions.
The frontend would like to store viewport information for each cell so
that visualizations are zoomed to the proper extents upon rendering.
This adds a property to cells called "axes" which takes the following
shape:
```
{
"axes" : {
"y" : {
"bounds" : [
0,
2
]
},
"y2" : {
"bounds" : [
1,
3
]
}
}
}
```
Bounds specify the visible range for the axis, and are a 2-tuple of the
form [lower, upper]. Bounds are not implicitly inclusive or
exclusive--that determination is left for clients to make. Also, there
are no restrictions on the naming of axes.
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
"Axis" is a more consistent and appropriate name. Also, the formatting
the protobufs was all over the place, so this has been made consistent
using a first-column \t. Furthermore, a vim modeline was added to the
bottom to make it easier for editors to autoconfigure themselves to the
right format, since protobufs are not something that we edit everyday.
Also, 32-bit values have been substituted for 64-bit values in Protobuf
definitions.
The frontend would like to store viewport information for each cell so
that visualizations are zoomed to the proper extents upon rendering.
This adds a property to cells called "axes" which takes the following
shape:
```
{
"axes" : {
"y" : {
"bounds" : [
0,
2
]
},
"y2" : {
"bounds" : [
1,
3
]
}
}
}
```
Bounds specify the visible range for the axis, and are a 2-tuple of the
form [lower, upper]. Bounds are not implicitly inclusive or
exclusive--that determination is left for clients to make. Also, there
are no restrictions on the naming of axes.
Clean up conditionals by refactoring to use loop label.
Incidentally this also fixed a bug that would not allow
a Kapacitor server to be added by the same name as one
that already existed, allowing the check to be removed
as well.
In order for :autoGroupBy: and :dashboardTime: to co-exist in a query,
it's necessary to introduce template variable precedence to the backend.
This is done by adding a `Precedence()` method to the TemplateVariable
interface that returns an ordinal indicating the precedence level of the
template variable. Precedence starts from 0 (highest) proceeding to the
maximum that a `uint` can represent.
A template variable at a given precedence level can expect that all
template variables with higher precedence will have already been
replaced in the query that is passed to its `Exec` call.
For example, :autoGroupBy: has lower precedence than :dashboardTime:
because it needs to know the selected time range for the query. When the
`Exec` method of `GroupByVar` is invoked, it will see the query after
:dashboardTime: has already been replaced, allowing it to extract the
duration successfully.
In order for automatic group by to be remotely useful, we need to parse
out the selected duration of time from the query itself. The problem
with doing this is that using the existing machinery for parsing
InfluxQL requires having valid InfluxQL, which InfluxQL+Template
Variables is not. To break this chicken-and-egg problem, the duration is
directly extracted from the query using regular string processing.
The httprouter used in Chronograf did not support prefixing every route
with some basepath. This caused problems for those using the --basepath
parameter in combination with a load balancer that did not strip the
basepath prefix from requests that it forwarded onto Chronograf.
To support this, MountableRouter prefixes all routes at definition time
with the supplied prefix.
* Introduce Kapacitor and InfluxDB as command line options
If omitted, their values will be null at runtime. If supplied, e.g.:
chronograf
--kapacitor https://path.to.my:1/kapacitor/instance
--influxdb https://path.to.my:1/influxdb/instance
Their values will be accessible via
Server.Kapacitor
Server.InfluxDB
* MultiSourcesStore will hold Bolt and config’d sources
* Delegate to db.SourcesStore for now
* Add Username/Password tags for InfluxDB and Kapacitor
* Builders for MultiSourceStore and MultiLayoutStore
* Store Kapacitor and InfluxDB configs in memory
* Typo
* Update CHANGELOG
* Move StoreBuilders to server/builders.go
* Correct these assertions by reversing them
* Kapacitor -> KapacitorURL; InfluxDB -> InfluxDBURL
* Correct documentation for dashboards
* Exclude .git and use 'make run-dev' in 'make continuous'
* Fix dashboard deletion bug where id serialization was wrong
* Commence creation of overlay technology, add autoRefresh props to DashboardPage
* Enhance overlay magnitude of overlay technology
* Add confirm buttons to overlay technology
* Refactor ResizeContainer to accommodate arbitrary containers
* Refactor ResizeContainer to require explicit ResizeTop and ResizeBottom for clarity
* Add markup and styles for OverlayControls
* CellEditorOverlay needs a larger minimum bottom height to accommodate more things
* Revert Visualization to not use ResizeTop or flex-box
* Remove TODO and move to issue
* Refactor CellEditorOverlay to allow selection of graph type
* Style Overlay controls, move confirm buttons to own stylesheet
* Fix toggle buttons in overlay so active is actually active
* Block user-select on a few UI items
* Update cell query shape to support Visualization and LayoutRenderer
* Code cleanup
* Repair fixture schema; update props for affected components
* Wired up selectedGraphType and activeQueryID in CellEditorOverlay
* Wire up chooseMeasurements in QueryBuilder
Pass queryActions into QueryBuilder so that DataExplorer can provide
actionCreators and CellEditorOverlay can provide functions that
modify its component state
* semicolon cleanup
* Bind all queryModifier actions to component state with a stateReducer
* Overlay Technologies™ can add and delete a query from a cell
* Semicolon cleanup
* Add conversion of InfluxQL to QueryConfig for dashboards
* Update go deps to add influxdb at af72d9b0e4
* Updated docs for dashboard query config
* Update CHANGELOG to mention InfluxQL to QueryConfig
* Make reducer’s name more specific for clarity
* Remove 'table' as graphType
* Make graph renaming prettier
* Remove duplicate DashboardQuery in swagger.json
* Fix swagger to include name and links for Cell
* Refactor CellEditorOverlay to enable graph type selection
* Add link.self to all Dashboard cells; add bolt migrations
* Make dash graph names only hover on contents
* Consolidate timeRange format patterns, clean up
* Add cell endpoints to dashboards
* Include Line + Stat in Visualization Type list
* Add cell link to dashboards
* Enable step plot and stacked graph in Visualization
* Overlay Technologies are summonable and dismissable
* OverlayTechnologies saves changes to a cell
* Convert NameableGraph to createClass for state
This was converted from a pure function to encapsulate the state of the
buttons. An attempt was made previously to store this state in Redux,
but it proved too convoluted with the current state of the reducers for
cells and dashboards. Another effort must take place to separate a cell
reducer to manage the state of an individual cell in Redux in order for
this state to be sanely kept in Redux as well.
For the time being, this state is being kept in the component for the
sake of expeditiousness, since this is needed for Dashboards to be
released. A refactor of this will occur later.
* Cells should contain a links key in server response
* Clean up console logs
* Use live data instead of a cellQuery fixture
* Update docs for dashboard creation
* DB and RP are already present in the Command field
* Fix LayoutRenderer’s understanding of query schema
* Return a new object, rather that mutate in place
* Visualization doesn’t use activeQueryID
* Selected is an object, not a string
* QueryBuilder refactored to use query index instead of query id
* CellEditorOverlay refactored to use query index instead of query id
* ConfirmButtons doesn’t need to act on an item
* Rename functions to follow convention
* Queries are no longer guaranteed to have ids
* Omit WHERE and GROUP BY clauses when saving query
* Select new query on add in OverlayTechnologies
* Add click outside to dash graph menu, style menu also
* Change context menu from ... to a caret
More consistent with the rest of the UI, better affordance
* Hide graph context menu in presentation mode
Don’t want people editing a dashboard from presentation mode
* Move graph refreshing spinner so it does not overlap with context menu
* Wire up Cell Menu to Overlay Technologies
* Correct empty dashboard type
* Refactor dashboard spec fixtures
* Test syncDashboardCell reducer
* Remove Delete button from graph dropdown menu (for now)
* Update changelog
Jared Scheib
Michael Desa
Chris Goller
Nathan Haugo
Tim Raymond
Timothy J. Raymond
Hunter Trujillo
Luke Morris
Andrew Watkins
Jade McGough
Jared Scheib