search

ushahidi / platform

Ushahidi Platform API version 3+
http://ushahidi.com
Other
677 stars 506 forks source link

Private survey and task fields #1511

Closed natmanning closed 7 years ago

natmanning commented 7 years ago

Expected behaviour

I can make a specific survey field, or task field, only visable to the logged in users, or by certain role. Particularly when doing verification, I want to include the original post details from FB for our internal team, but they have PII on them so I dont' want them published. This means I have to delete the content or not publish it.

Actual behaviour

All fields are public

Steps to reproduce the behaviour/error

jshorland commented 7 years ago

@brandonrosage @rjmackay this has been a highly highly requested feature and has significant implications for security/privacy issues, as well as strategic partnerships that will benefit Ushahidi business and brand.

I'd like to move this along quickly if possible.

brandonrosage commented 7 years ago

In the interest of a quick implementation, I've cooked up a revision to the "Edit survey" view (which is also a proxy for the "Create survey" view) that helps us clean up that experience, and adds the ability to fine-tune the permissions around individual fields.

Some quick notes, though:

Here's an average "Edit Survey" view:

Edit Survey

Some notable changes:

Survey name and description

The survey's name and description take on a similar visual treatment to the actual survey form's display -- except they're editable:

edit survey name

Fields and settings

The survey's fields and settings have been grouped in a way that better lends itself to onboarding and new survey creation, by grouping them in tabs (e.g. Build, Configure, Share). By default (and first), you see "Build," which focuses entirely on building the data collection model.

"Configure" offers controls for visibility, permission, and color:

configure

"Share" prompts you to share your survey's URL, grab the embed code, share on Facebook, etc:

share

Now, to the matter of "private fields"...

'Who can see the response to this field'

In the "Build" tab, each field can be configured by selecting its name. And you can add a new field by selecting "Add field." In either case, you see a modal window with controls for each of its settings.

If I choose to "Add field," for example, I first select the field type (e.g. short text) and then I see:

add field

The key new field here is "Who can see the response to this field," whose value is always "everyone" by default.

I can easily change this so that only "Editors" can see the response to this field:

specific roles

Now, when I save and close the window, that field will be appended to the list of fields with an indicator to the right of the field's label:

list item

It doubles as a tooltip, with more detail on hover:

tooltip

Similarly, when I view a detail view for any response to this survey (assuming I have permission to see it), this field's label will have the same indicator/tooltip:

detail view

All of this is demonstrated in a feature-specific branch in the Pattern Library, largely in the "Edit survey" layout.

I'd really appreciate your feedback on this reasonably quick solution, @caharding and @jshorland.

jshorland commented 7 years ago

@brandonrosage This looks really really good. Thank you for the quick turnaround on this. Can you assign a dev to take a look from a tech perspective?

On Jan 28, 2017, at 12:25 AM, Brandon Rosage notifications@github.com wrote:

In the interest of a quick implementation, I've cooked up a revision to the "Edit survey" view (which is also a proxy for the "Create survey" view) that helps us clean up that experience, and adds the ability to fine-tune the permissions around individual fields.

Some quick notes, though:

This ignores "Tasks" for the moment. The "delete" button for surveys has moved to the "Surveys" listing, embedded in each survey's summary list item. All of this work is done using existing patterns in the PL. Here's an average "Edit Survey" view:

https://cloud.githubusercontent.com/assets/1136279/22387424/39d2da96-e4a1-11e6-8823-1f10e1a8570e.png Some notable changes:

Survey name and description

The survey's name and description take on a similar visual treatment to the actual survey form's display -- except they're editable:

https://cloud.githubusercontent.com/assets/1136279/22387486/72fad008-e4a1-11e6-91e5-cb9c1fd065f6.png Fields and settings

The survey's fields and settings have been grouped in a way that better lends itself to onboarding and new survey creation, by grouping them in tabs (e.g. Build, Configure, Share). By default (and first), you see "Build," which focuses entirely on building the data collection model.

"Configure" offers controls for visibility, permission, and color:

https://cloud.githubusercontent.com/assets/1136279/22387598/fd7cfb52-e4a1-11e6-9e79-04b8f061f447.png "Share" prompts you to share your survey's URL, grab the embed code, share on Facebook, etc:

https://cloud.githubusercontent.com/assets/1136279/22387650/3c216f50-e4a2-11e6-86cc-f8416de8a3fb.png Now, to the matter of "private fields"...

'Who can see the response to this field'

In the "Build" tab, each field can be configured by selecting its name. And you can add a new field by selecting "Add field." In either case, you see a modal window with controls for each of its settings.

If I choose to "Add field," for example, I first select the field type (e.g. short text) and then I see:

https://cloud.githubusercontent.com/assets/1136279/22387759/d596e52a-e4a2-11e6-99c4-cb5010d54b2a.png The key new field here is "Who can see the response to this field," whose value is always "everyone" by default.

I can easily change this so that only "Editors" can see the response to this field:

https://cloud.githubusercontent.com/assets/1136279/22387848/3588527a-e4a3-11e6-8848-bcc2da59ae4f.png Now, when I save and close the window, that field will be appended to the list of fields with an indicator to the right of the field's label:

https://cloud.githubusercontent.com/assets/1136279/22387877/60a91d9a-e4a3-11e6-9078-c854881188b4.png It doubles as a tooltip, with more detail on hover:

https://cloud.githubusercontent.com/assets/1136279/22387901/756acf26-e4a3-11e6-93e5-59c35e295bcf.png Similarly, when I view a detail view for any response to this survey (assuming I have permission to see it), this field's label will have the same indicator/tooltip:

https://cloud.githubusercontent.com/assets/1136279/22387962/bbf58242-e4a3-11e6-85b9-b0c6213bec5c.png All of this is demonstrated in a feature-specific branch https://github.com/ushahidi/platform-pattern-library/tree/f-fields_and_sections in the Pattern Library, largely in the "Edit survey" layout http://preview.ushahidi.com/platform-pattern-library/f-fields_and_sections/assets/html/5_layouts/settings-survey-edit.html.

I'd really appreciate your feedback on this reasonably quick solution, @caharding https://github.com/caharding and @jshorland https://github.com/jshorland.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ushahidi/platform/issues/1511#issuecomment-275778898, or mute the thread https://github.com/notifications/unsubscribe-auth/ADE1GHb7O3jFhfP3cTdpUG6Qcb-cody8ks5rWmDjgaJpZM4K0rrI.

brandonrosage commented 7 years ago

@aoduor, @KrisKuri: Please verify that I've addressed this and any relevant user stories that demand a solution like this. I want to make sure I've covered the need completely.

aoduor commented 7 years ago

@brandonrosage solid in my opinion! quick question: we have a "hide author" option, so i'm assuming that we're now going to offer fields collecting author information by default?

aoduor commented 7 years ago

Wondering if this issue here also addresses https://github.com/ushahidi/platform/issues/1560?

brandonrosage commented 7 years ago

we have a "hide author" option, so i'm assuming that we're now going to offer fields collecting author information by default?

@aoduor: No, the "hide author information" option for surveys isn't intended to suggest there would be new or additional fields. Nothing would change about how we handle capturing author data.

That control is simply an extension of the user story here -- that the contributor may be fine with the content of their response being publicly visible, but not some (or any) of their information or attribution. That control ensures that, not only would survey fields that collect personal information be optionally protected, but potentially everything about the author.

brandonrosage commented 7 years ago

Wondering if this issue here also addresses #1560?

From what I can tell, @aoduor, I don't think this solution addresses #1560. That issue seems to imply that deployers might need to make whole surveys invisible to its users. If that's the case, it doesn't really touch on contributor's privacy because it would potentially never make the survey visible to those users to begin with.

That said, the solution above does suggest where a control like the one described in #1560 would live, and how deployers would access it.

willdoran commented 7 years ago

@jshorland @brandonrosage Does the Survey Field Role setting Supersede the Survey role or how do the two relate? Is the latter only for restricting who can submit or does it control visibility as well?

ie.

rjmackay commented 7 years ago

Just adding to this. The design shows a 'Who can submit responses to this survey' and 'Who can see the response to this field'

If I can submit responses to a survey, but not see responses to a field. Can I submit responses to that field?

jshorland commented 7 years ago

@willdoran asked: "Does the Survey Field Role setting Supersede the Survey role or how do the two relate? Is the latter only for restricting who can submit or does it control visibility as well?"

ie.

It's an excellent question. Field level permissions should supercede survey permissions in terms of who can SEE and EDIT responses to the particular field, but not in terms of who can CONTRIBUTE.

@brandonrosage is this right?

brandonrosage commented 7 years ago

Great catch, @willdoran and @rjmackay. And I think it calls for a revision to this direction that'll help simplify things.

In short, instead of asking deployers to choose a role that can "see responses to this field," let's do what we do with post status: Make it something you can lock (or unlock).

So when editing a field that you intend to make "private," you'll see a switch to "Make responses private":

edit field

By turning this option "on," you see some help text:

field locked

And when a survey response was submitted, only users with permission to edit that response would see the following in the response's detail view:

detail view

Otherwise, the user simply wouldn't see the field at all. The same logic would apply to the response's "edit" view.

So let's be clear. When a field's responses are marked private:

As I understand it, this would greatly simplify the cascade of permissions. True, @willdoran?

willdoran commented 7 years ago

@brandonrosage Yes, this would be vastly simplify the implementation and removes any of the potential weird collisions. Thanks!

willdoran commented 7 years ago

@brandonrosage @jshorland I should point out though this is not field level permissions, it's more field level locking. It means that I can't give limited edit access to a post. So if I want someone to be able to edit only parts of a post I can't do that, either they can edit it all or none of it.

Is that ok? This does seem to fit the original issue description which was only concerned by visibility.

I'm going to proceed with the latest description.

brandonrosage commented 7 years ago

That's right, @willdoran. The permissions effect visibility in detail and postcard presentation. Not editing. By making a field "private," you're simply saying that only the people who can edit the post will also see its private fields in detail and postcard presentations.

jshorland commented 7 years ago

That’s right, @willdoran. Thanks for pointing out this difference though

Jess Shorland Product manager jess@ushahidi.com

On Mar 17, 2017, at 12:36 PM, Brandon Rosage notifications@github.com wrote:

That's right, @willdoran https://github.com/willdoran. The permissions effect visibility in detail and postcard presentation. Not editing. By making a field "private," you're simply saying that only the people who can edit the post will also see its private fields in detail and postcard presentations.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ushahidi/platform/issues/1511#issuecomment-287421719, or mute the thread https://github.com/notifications/unsubscribe-auth/ADE1GCp0Bcd5f7MuK2ChFD8SKqEteEeKks5rmsSMgaJpZM4K0rrI.

rjmackay commented 7 years ago

I do love when our speccing process results in an overall clearer and simpler feature.. not just better technical implementation.

rjmackay commented 7 years ago

@willdoran FYI I ping'd @jshorland about the name change from (ie. tasks -> sections). AFAIK that should actually be happening/implemented.

@brandonrosage was that intentional or something that slipped in? I'd really like to see name changes 1. called out explicitly 2. avoided unless theres a solid, user tested reason to change..

When we change names it makes the codebase harder to understand because now the components names in code don't match the UI.. or we have to rename them in code, which can be error prone.

brandonrosage commented 7 years ago

@rjmackay The term "sections" largely slipped in. I do want to make a case for it, however, based on my user interviews with deployers regarding "tasks."

@jshorland and I discussed this in a call this morning and I'll be joining your next one-on-one briefly to talk about it there, as well.

In short, the argument has two components:

  1. "Tasks" in the product today don't behave much like tasks. They're the start of a feature conceived using mothballed user stories. So using the label in the product's existing feature set today is problematic in that regard.

  2. My first pass at the feedback from existing deployers suggests that, not only would they choose a different term for what they're trying to do, but that their need does not amount to an abstraction or separate thing from survey content; but rather amounts to the means to wrap logic and workflow around specific pieces (ahem, sections) of their surveys.

Talk soon.

caharding commented 7 years ago

I find this slightly confusing. Sections of a survey read to me "You did part 1, now fill out part 2" but in reality, a user may just do part 1, and then a different user type would do part 2. This gets particularly confusing especially when the person to submit can't actually submit b/c something else has to be done to the survey.

On Mon, Mar 27, 2017 at 11:40 AM, Brandon Rosage notifications@github.com wrote:

@rjmackay https://github.com/rjmackay The term "sections" largely slipped in. I do want to make a case for it, however, based on my user interviews with deployers regarding "tasks."

@jshorland https://github.com/jshorland and I discussed this in a call this morning and I'll be joining your next one-on-one briefly to talk about it there, as well.

In short, the argument has two components:

1.

"Tasks" in the product today don't behave much like tasks. They're the start of a feature conceived using mothballed user stories. So using the label in the product's existing feature set today is problematic in that regard. 2.

My first pass at the feedback from existing deployers https://drive.google.com/open?id=0B76oN-t_b0xBS3FNYl9YWHFtUkU suggests that, not only would they choose a different term for what they're trying to do, but that their need does not amount to an abstraction or separate thing from survey content; but rather amounts to the means to wrap logic and workflow around specific pieces (ahem, sections) of their surveys.

Talk soon.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ushahidi/platform/issues/1511#issuecomment-289545769, or mute the thread https://github.com/notifications/unsubscribe-auth/ABizaStUvLcxHd1Jv5h9YGUplDUxOASnks5rqAKngaJpZM4K0rrI .

-- Charlie Harding Product Director

jshorland commented 7 years ago

@charlie we're not making a decision on "sections". Keeping them as tasks, as we need more information.

jshorland commented 7 years ago

@willdoran is there a specific url where I should be testing this, or just on qa.ushahididev.com? And any dependencies that I should be testing too?

willdoran commented 7 years ago

@jshorland Hey, it should be in qa.ushahididev.com and I don't think there are any dependencies

jshorland commented 7 years ago

@willdoran notes from my QA:

willdoran commented 7 years ago

@jshorland will fix on flight and send update later today

jshorland commented 7 years ago

@willdoran the only issue I still see is not seeing a photo even though I upload it and have marked the field as private and am logged in as an admin, but it might be because @angamanga fixed an issue with photo upload recently? All other fields, when marked as "private" work as we want them to.

And whooaaaa... duplicate task is there. and it works. and its kind of blowing my mind. Who caused so much delight in my day?

jshorland commented 7 years ago

@willdoran how hard would it be to add "duplicate survey"? I can make a new issue if necessary, but curious if we can slip that in there too?

jshorland commented 7 years ago

@willdoran -- should I test duplicate surveys yet? Private fields work perfectly so I don't want to hold that up if we don't need to.

willdoran commented 7 years ago

@jshorland yep I merged duplicates as a separate so they are ready to test. It doesn't have an associated issue though. Field level is good to go since you've ok'd it. So we can close this.

rjmackay commented 7 years ago

Hide author feature is relevant to this intercom conv: https://app.intercom.io/a/apps/hl5rfiga/respond/inbox/jess@ushahidi.com/conversations/9555218421