Previously, as a misunderstanding of
https://github.com/influxdata/chronograf/issues/1915 we allowed
sources to be scoped by role within an organization. This was incorrect.
We no longer user the roles implementation of a chronograf.SourcesStore
and just use the organizations store.
We've left the code around a roles SourcesStore in place, since it may
be useful to us in the future. It may be worth removing if it is
determined that this behavior is not desirable.
Previously, each store depended on having an organization set on the
implentation of a store. This was used to segment different
organizations into different buckets. This PR undoes that work.
Signed-off-by: Jared Scheib <jared.scheib@gmail.com>
bolt/organization_users_store contains a boltdb implementation of a
chronograf.UsersStore that filters the results based on the organization
that is set on the context.
Signed-off-by: Jared Scheib <jared.scheib@gmail.com>
For each organization, we create a set of buckets for each associated
resource (sources, servers, layouts, and dashbaords).
The bucket name is the path join of the resource bucket name and the
oranizations name. If the organizations name is empty, then the bucket
name is the resource bucket name (this is backwards compatible with how
resources are currently stored).
Signed-off-by: Jared Scheib <jared.scheib@gmail.com>
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.
Alex P
Jared Scheib
Michael Desa
Deniz Kusefoglu
Jared Scheib
deniz kusefoglu
Chris Goller
Andrew Watkins
Luke Morris
Nathan Haugo
Tim Raymond
Timothy J. Raymond
Hunter Trujillo