Allow users to tag dashboards #3821
mnemalur posted onGitHub
Make sure these boxes are checked before submitting your issue - thank you!
- [ Y] I have checked the superset logs for python stacktraces and included it here as text if any
- [ Y] I have reproduced the issue with at least the latest released version of superset
- [ Y] I have checked the issue tracker for the same issue and I haven't found one similar
Superset version
0.19
Expected results
I Would love to find a way to group multiple dashboards into logical groups and restrict access to each group. Like Folder A -- > Dashboard1, Dashboard2, Folder B -- > Dashboard3, Dashboard4 etc.. When we list all Dashboards on the screen once you have too many , u need to use the filter criteria,. Instead can we group them.
Actual results
Steps to reproduce
I second that. It would be useful to provide folders (or tags?!) for, e.g., departments or other categorical criteria.
I use the datasources as a way to distinguish between departments / whatever.
We will provide Tabs for dashboard, currently under design and discussion.
It would be nice to do the slices too
.(provide folders (or tags?!))
@graceguo-supercat
I love the idea of tagging, rather than tabs or folders. That would allow a single dashboard to appear in multiple groups.
If we do go down that route - I'd love to be able to set a specific tag to control the dashboards available on the welcome page. That way we can direct people to a specific curated set of dashboard as a starting point.
I agree this is a nice feature, we want to role this out to 2000 people and the more we can group the better. Has anyone done any more design on limiting view of slices and dashboards besides the default with data sources? On think i was thinking if we get the feature in this issue, maybe we can get by with having a simple version of the privs. with a private flag. By default a private flag would limit the dashboard to just the user who created it. Might need to carry that down to slices. Should I start a thread on that?
Group the dashboards into Folders,I like this feature.
I also prefer tagging over groups
Few notes:
- tags should be create as a many to many relationship in the db, eventually can be reused to tag slices using the same tag namespace but that lower pri
- most of the UI stuff (filtered Dashboard list view, tag creation / association) can be done automagically in FAB by just setting the model and modelviews properly
- tags should be surfaced right of the dashboard title ("label-default"), with click navigation taking users to filtered dashboard list
To summarise some of the things people have mentioned, and some things which are still a bit less defined.
General Concensus Summary
- Tags or Folders?: Tags
- Many to many relationships. i.e. one tag can be applied to many dashboards, one dashboard may have many tags.
- Same namespace to tag both dashboards and slices. By clicking on a tag you can see both the dashboards and slices associated with that tag. Effectively filtering the list
- Tags will be shown as coloured tabs just to the right of the dashboard title. Bootstrap
badge
style
Open Questions
- Some people have mentioned tags which would confer some special functionality, like a
private
tag which means only you can see it, or afeatured
tag which would automatically bring things to the front of a list - or put them onto the front page. Is this something where there are sufficiently few use cases that we should have a few "magic" tags which have special hardcoded features - or is this something that should be configurable.- as a followup, are there certain tags which should be automatically implemented as a result, i.e. bundled into a standard setup when calling
superset init
. - should some tags be automatically applied to new slices - e.g. a slice is automatically tagged as private until explicitly shared? Perhaps a dashboard should be automatically private until tagged with the shared tag - although my preference is to default to shared rather than default to private.
- as a followup, are there certain tags which should be automatically implemented as a result, i.e. bundled into a standard setup when calling
- Should tags all be the same colour (grey/superset-teal) - or is colour something that should be configurable for a given tag?
- Should tags be visible on the dashboards themselves? Or are they something that is just shown in list views etc...? Likewise should tags for slices be shown on the explore view?
What do you guys reckon? Anything else I've missed? @mistercrunch @xrmx @graceguo-supercat @luciuschina @rpwils @rumbin @bbs2009 @mnemalur
Hi Alan, Thanks for writing this up. here are my 2 cents.
- I like the idea of having a "private" or "published" tag for dashboards, maybe that can be a setting to default them dashboards as private or not?
- As for other Magic tags, I like the idea of using a tag to bring dashboards to the front. Not sure its essential.
- People seem to like different colored tags, Im not really all that concerned.
- I don't think they need to be on the dashboard itself, it would only take up room.
Would this also go on slices?
On Tue, Dec 5, 2017 at 1:41 PM, Alan Cruickshank notifications@github.com wrote:
To summarise some of the things people have mentioned, and some things which are still a bit less defined. General Concensus Summary
- Tags or Folders?: Tags
- Many to many relationships. i.e. one tag can be applied to many dashboards, one dashboard may have many tags.
- Same namespace to tag both dashboards and slices. By clicking on a tag you can see both the dashboards and slices associated with that tag. Effectively filtering the list
- Tags will be shown as coloured tabs just to the right of the dashboard title. Bootstrap badge style https://getbootstrap.com/docs/4.0/components/badge/
Open Questions
- Some people have mentioned tags which would confer some special functionality, like a private tag which means only you can see it, or a featured tag which would automatically bring things to the front of a list - or put them onto the front page. Is this something where there are sufficiently few use cases that we should have a few "magic" tags which have special hardcoded features - or is this something that should be configurable.
- as a followup, are there certain tags which should be automatically implemented as a result, i.e. bundled into a standard setup when calling superset init.
- should some tags be automatically applied to new slices - e.g. a slice is automatically tagged as private until explicitly shared? Perhaps a dashboard should be automatically private until tagged with the
- shared* tag - although my preference is to default to shared rather than default to private.
- Should tags all be the same colour (grey/superset-teal) - or is colour something that should be configurable for a given tag?
- Should tags be visible on the dashboards themselves? Or are they something that is just shown in list views etc...? Likewise should tags for slices be shown on the explore view?
What do you guys reckon? Anything else I've missed? @mistercrunch https://github.com/mistercrunch @xrmx https://github.com/xrmx @graceguo-supercat https://github.com/graceguo-supercat @luciuschina https://github.com/luciuschina @rpwils https://github.com/rpwils @rumbin https://github.com/rumbin @bbs2009 https://github.com/bbs2009 @mnemalur https://github.com/mnemalur
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/incubator-superset/issues/3821#issuecomment-349417625, or mute the thread https://github.com/notifications/unsubscribe-auth/AHOWzECpct2mbN8lHpCCchZIRu3yMSIeks5s9ZxRgaJpZM4QYrRW .
hi @alanmcruickshank just checking in to see if you have been able to make progress?
thanks!
Agreed! @alanmcruickshank logical groupings of dashboards would be an extremely valuable functionality to have. Our list of dashboards are getting a little out of hand.
@mistercrunch Looking at taking a stab at this as we could really use it... from you comments above. does this work for you on the db side. 3 simple tables
tags id tag_name tag_color ….
dashboard_tags id dashboard_id tag_id
slices_tags id slice_id tag_id
@rpwils - I've not managed to make a stab at this, been completely snowed with a couple of other things. I like your suggested table schema. Having a separate id
primary key column in dashboard_tags
and slices_tags
is in line with the format of dashboard_slices
rather than having a two column table with a composite primary key.
The existing table slice_user
suggests that we should call the tag table slice_tag
rather than slices_tags
.
And allowing permissioning based on tags would be a good solution to #1799.
Well @mcdavey17 that may mean seriously restricting who can tag dashboards though.
Permissions on tags could be a useful second stage but seems like a lot of scope creep for "tagging v1".
For it to not be super restrictive - we could assume all tags can be freely used and created but that there are a subset of specific "protected" tags which require specific permissions (and optionally those tags could also impart specific effects to the objects tagged with them). Building things that way could also be nice in keeping the mechanics of tags and the effects they impart separate.
On Mon, 19 Feb 2018, 00:22 Maxime Beauchemin, notifications@github.com wrote:
Well @mcdavey17 https://github.com/mcdavey17 that may mean seriously restricting who can tag dashboards though.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/incubator-superset/issues/3821#issuecomment-366562258, or mute the thread https://github.com/notifications/unsubscribe-auth/AEdFuIZTBN4F-rYrEjnx6Ad43zw6qCNlks5tWL6ugaJpZM4QYrRW .
--
Alan Cruickshank E: alanmcruickshank@gmail.com T: +44 770 6851825
@rororofff has funded $15.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned
to prevent stale bot from closing the issue.