Make org/user data available via reports interface

[svenaas]

Work to satisfy #4258, adding new reports with orgs and user/org/role information available as CSVs for import into ZenDesk. These reports are presented in the Admin UI as well (slightly differently), with the CSV downloads available from this interface, or potentially via direct calls to the API.

Changes proposed in this pull request:

• Move the existing /organizations-report to /reports/published-sites
• Add a new organizations report (that includes all orgs, not just those with published sites) at /reports/organizations
• Add a new users report that includes associated organizations and roles at /reports/users

security considerations

None. The data presented is only available to authenticated admin/support users, and only represents data already available to those users.

[drewbo]

Redeployed and tested on dev. Added another org to see multiple org users. Everything looks good. The only minor (optional) thing is I'd name the columns "Github email" and "UAA email" for consistency with the users view. Good to go once rebased

[svenaas]

The only minor (optional) thing is I'd name the columns "Github email" and "UAA email" for consistency with the users view.

I agree with that. But the CSV export just has an "Email" (UAA) column for ZenDesk convenience as of this writing. Does that seem OK to you, @drewbo?

[svenaas]

@drewbo, I changed the email column names and order in the users report to match the users administration page — that needs a re-review. But you can't just read that change because I also rebased this down to three discrete commits (you'd probably go with one, and I can do that if you prefer).

[svenaas]

Hold off on that, please; test is behaving differently in Concourse because I wasn't careful about ordering. Fixing that now.

[drewbo]

Can you change the new report commits to feat(admin): type? I'm not positive how the changelog will handle that but it better reflects those changes

[svenaas]

Yes. Done.

[drewbo]

One last code piece I should have checked earlier: can you abstract the downloadCSV function to accept the csv as input, and put this in a util file? (otherwise it's duplicated three times)

[svenaas]

Yeah, sure (sigh) that's a good idea. I should have thought of that as I based two new Svelte files on the first one.

[svenaas]

OK, @drewbo, it's in helpers now; please take a particular look at the way I'm defining the helper function and passing parameters in. Do you think this refactoring is good, or do you think it would be better to go a step further and make a CSVDownloadButton Svelte component? Because I could try that too.