Thanks for Tresdon, this is a good feature. 

+1

- Grace



> On Jul 8, 2019, at 3:12 PM, Tresdon Jones <[email protected]> wrote:
> 
> Thanks for the insight!
> 
> To address the migration concern for those who may have it – The DB
> migration now sets all dashboards to be published on migration so the UX of
> the users shouldn't change besides seeing a new "Published" badge next to
> dashboards they own. For dashboards users don't own nothing will change.
> Once users click on the "Published" badge they will see it change to a
> "Draft" badge which intends to helps users understand how their actions
> affect the state of the dashboards, before this interaction occurs nothing
> will change and no dashboards will be out of sight.
> 
> If there are any other concerns please feel welcome to share. I would love
> to write up how the feature behaves in the user documentation – I'm
> thinking of putting it in tutorial.rst as of now but perhaps there's a
> better place for it?
> 
> Kind Regards,
> Tresdon
> 
> On Mon, Jul 8, 2019 at 12:44 PM Erik Ritter <[email protected]>
> wrote:
> 
>> +1 from me!
>> 
>> I think some of the delay for LGTM-ing this PR came from ensuring the db
>> migration would let us launch the feature without any change to the current
>> user experience. Also, the cognitive overhead from catching up on >50
>> comments for context. Regardless, I think that it's an awesome feature, and
>> I'm really grateful for the unit tests too!
>> 
>> Erik
>> 
>> On Mon, Jul 8, 2019 at 10:13 AM Tresdon Jones <[email protected]>
>> wrote:
>> 
>>> Very glad to see such outstanding support for this feature!
>>> 
>>> I must say I'm a bit confused as to what and where the grievances /
>>> blockers are because I'm not seeing them on the PR or on this thread. Are
>>> they happening on some synchronous communication channel that I'm not
>>> looped in on? I would like to address these issues and make this work for
>>> as many folks as possible but that is hard when I do not see the
>> objections
>>> raised. Some clarification / ideas about next steps would be very much
>>> appreciated.
>>> 
>>> Best always,
>>> Tresdon
>>> 
>>> 
>>> On Mon, Jul 8, 2019 at 1:32 AM Matthew Mutee <[email protected]> wrote:
>>> 
>>>> +1. Would be useful to us.
>>>> 
>>>> Regards,
>>>> Matthew M. Mutiso
>>>> 
>>>> 
>>>> 
>>>> On Tue, 2 Jul 2019 at 20:32, Tresdon Jones <[email protected]>
>>>> wrote:
>>>> 
>>>>> Hello all,
>>>>> 
>>>>> I want to gather some sentiment around this PR which allows users to
>>>>> communicate whether their dashboards are for general consumption or
>> for
>>>>> their own purposes (work to be done before general consumption,
>>> esoteric
>>>>> dashboards / charts, or "this is a test" type dashboards). It aims to
>>>>> declutter the main area for listing dashboards by filtering on this
>>>> status.
>>>>> 
>>>>> https://github.com/apache/incubator-superset/pull/4725
>>>>> 
>>>>> 
>>>>> This PR will introduce a few changes to different parts of the
>>>> application:
>>>>> 
>>>>> DB changes:
>>>>> 
>>>>>   1. A DB migration will add the boolean field "published" to the
>>>>>   dashboards table in superset.db. It will set all dashboards to
>>>>> published on
>>>>>   migration so that all dashboards remain visible.
>>>>> 
>>>>> UI changes:
>>>>> 
>>>>>   1. On listing dashboards through the "dashboards" link at the top
>> of
>>>> the
>>>>>   application there will be a new sortable column called
>> "published".
>>>>>   2. Dashboards will have a badge at the top of them next to the
>>> favstar
>>>>>   communicating the status of it (Draft or Published) *unless* the
>>>>>   dashboard is already published and the viewing user has no
>>> permissions
>>>>> to
>>>>>   change it.
>>>>>   3. The aforementioned badge can be clicked to toggle the status of
>>> the
>>>>>   dashboard or it can be edited through the dashboard CRUD view.
>>>>> 
>>>>> 
>>>>> 
>>>>> I would very much appreciate a response of +1 if this would be a
>> useful
>>>> and
>>>>> welcome feature in your environment and a -1 with grievances if there
>>> are
>>>>> objections regarding – this would provide exigency for putting a
>>> feature
>>>>> flag in front of this functionality. Many thanks in advance for your
>>>>> participation!
>>>>> 
>>>>> Best always,
>>>>> Tresdon
>>>>> 
>>>> 
>>> 
>> 

Reply via email to