BUG: CSV Export history should ONLY show exports from the logged in user

[rowasc]

Expected behaviour

• When I see my exports history, I only see the ones that belong to me

Actual behaviour

• When I see my exports history as an admin, I see all the exports

Steps to reproduce the behavior/error

• Login to http://csvexportsforever.v3-qa.ush.zone/settings/data-export or another qa deployment from v3-qa.ush.zone
• Go to the exports page
• Go to the history tab
• Expected behavior: You should only see your exports
• Current behavior: You see all exports

Where

• Local setup with Vagrant
• Local setup from platform-release
• Ushahidi.io / SaaS solution
• Ushahidi's QA environment (in v3-qa.ush.zone)
• Other (explain):

[rowasc]

@Angamanga I couldn't reproduce this.

[caharding]

@Angamanga can you see if you can recreate this?

[Angamanga]

@rowasc @caharding Unfortunately, yes I can reproduce it on .io. I created a new user and went to the data-export in settings and started an export. In the export-history-tab I see all export-jobs that is finished from all users.

I also see all the export-jobs in the response from the api so its not a caching-issue.

[willdoran]

Spec:

• Export Job History should show only export jobs from the currently logged in user, when user has bulk data permissions but is not an admin
• Export Job Repository should filter export jobs by current user when user has bulk data permissions but is not an admin
• Admin users should see all jobs and see who each job is created by

[Angamanga]

@willdoran Looks good, moving to ready for dev!

[jrtricafort]

Needs a new spec. @willdoran

[rowasc]

@jrtricafort do you remember why this was flagged as "needs a new spec" ?

[jrtricafort]

@rowasc That comment was to capturing something from a conversation I had with @willdoran , but I don't recall the specifics. Will do you remember? If not, I think we can probably ignore that for now, since we have prioritized this as P2 so not as high a priority.

[rowasc]

Thanks @jrtricafort. I'd prefer to move this to cycle 7 if it's really a P2 for us , since cycle 6 is pretty full at the moment and we're even behind on specs :/

[jrtricafort]

@rowasc Done

[crcommons]

@willdoran Do you recall your conversation with Juan about why this needed new spec?

[willdoran]

@crcommons I think though I failed to write this down it's because admin users should not see all jobs but only their own. But may be double check that with @jrtricafort

[jrtricafort]

@willdoran @crcommons That's correct. Admin users should only see their jobs.

There's some ambiguity here, because we do tend to give admin users lots of superpowers over lots of their own deployments. But seeing all exports with the username (as was originally spec'd for this issue back in May) is more like an audit of other users' behavior, and at no other point in the UX do we support that. If there is ever a use-case where someone actually needs to see who is exporting what, that is more of a privacy workflow and that should be treated as a separate special thing (which doesn't currently exist outside of hitting up the DB directly on the backend).

So long story short, yep, even admins should just see their own exports in export history.

[crcommons]

@jrtricafort I've implemented this fix in develop, however, with Kohana (which is in production) we have it so that users who have all manage settings can't even access exports at all, let alone their own exports. Is this something we need to change now in production or can we wait until lumen is released?

Screenshot shows a logged in user with manage settings, posts, and users. Clearly this user cannot do those things.

[rowasc]

@jrtricafort @crcommons I added an issue about Manage Settings not allowing some of the permissions it states in the docs that we allow. #3169
Manage settings is not supposed to allow a CSV download as far as I know but I realized that we also are not giving users with Manage Settings the permission to see / edit categories .

[crcommons]

UPDATE:

• Changes in master have been merged in client and API and waiting to deploy;
• changes in develop have been merged in API and waiting to deploy;
• changes in develop in client are waiting for review

[crcommons]

Update: changes in client have been merged into develop.

[Eve-wanderi]

@rowasc This has passed for QA.

[Eve-wanderi]

Confirmed in http://targetedsurveytesting.v3-qa.ush.zone/ works as expected.