Add definitions for user roles and permissions in chronograf package
Signed-off-by: Jared Scheib <jared.scheib@gmail.com>
Signed-off-by: Michael de Sa <mjdesa@gmail.com>
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>
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.
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.
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.
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
Previously, if bounds were not set, the default value that would be
returned was ["0", "0"], which is incorrect. This now returns [] when
there was nothing set for a particular axis.
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.
There were previously no tests around Dashboard serialization to
protobuf, so this patch adds coverage for that. Also, the `go-cmp`
package has been introduced to replace our usage of `reflect.DeepEqual`
going forward because it has better comparison features that make it
more stable across Go versions and produces nice diffs in tests when
they fail, reducing the need for debug lines and manual inspection.
"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.
There were previously no tests around Dashboard serialization to
protobuf, so this patch adds coverage for that. Also, the `go-cmp`
package has been introduced to replace our usage of `reflect.DeepEqual`
going forward because it has better comparison features that make it
more stable across Go versions and produces nice diffs in tests when
they fail, reducing the need for debug lines and manual inspection.
"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.
* 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
This divides templates into two classes: autoflow and static. This is
controlled by a boolean "autoflow" property on templates. Any autoflow
templates that will be rendered for a host, have their cells arranged in
a left-to-right, top-to-bottom fashion.
Static templates, are assumed to have precise positioning information
for their graphs. The only adjustment made to them will be a translation
of their Y coords so they do not overlap other layouts.
The autoflow templates, after processing, become a static layout as
defined above and are positioned accordingly.
Most of the other private CRUD methods have a consistent argument order
of a context, a source, then a transaction. setRandomDefault had two of
these args transposed, so this swaps them to be consistent with the rest
of the methods.
Previously, the logic to enforce on default source relied on the
public-facing CRUD methods already provided by SourcesStore. This was
prone to deadlocks due to the possibility of acquiring a transaction
within a transaction. This extracts the logic that was performed within
the transactions of each CRUD action and makes the private methods that
receive a *bolt.Tx. This allows the convenience methods that enforce
default source to use this private API and provide the transaction from
its caller. This ensures that there is only ever one transaction
acquired by each expored
CRUD method.
Whenver sources are present, there should be exactly one default source.
Prior to this commit, it was possible to add the first source as a
non-default source and circumvent this invariant. This unfortunately
requires a bit of special-casing logic in s.Add and requires a query to
fetch the number of sources currently persisted.
Tests have been added to cover this as well as deleting the final
source, to ensure that there aren't any odd indexing panics that might
result from trying to find another candidate default source when
deleting.
Enforcing the constraint that there be exactly one default source
whenever there are sources present isn't really a concern of the
traditional CRUD methods that are provided by SourcesStore. This makes
this separation a little more explicit and provides a place to glue some
documentation onto what would otherwise be a confusing bit of business
logic in the write path of SourcesStore.
Previously, when adding a new default source, it was possible to create
more than one default source, since the previous default would not be unset.
Implementing this revealed another issue where deleting the default
source would leave no default set. If the default source is deleted now,
another source is chosen to be the new default.
This ensures that there will only be on default source upon setting a
new default by unsetting the default flag on all other sources. This
only happens when the source to be updated has Default set to true to
avoid a performance hit when updating other attributes.
I and Name were added to support react-grid-layout. They were added to
the chronograf types, but not to the protobuf definitions, so the only
layouts that could make use of them were the canned variety. This allows
layouts' I and Name to be persisted as well.
Michael de Sa
Jared Scheib
Chris Goller
Andrew Watkins
Tim Raymond
Hunter Trujillo
Jade McGough
Jared Scheib
Will Piers
gunnaraasen