Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Description • 10 years ago

Products listed as "not public" are still visible via the API.

There are two problems with this:

1. "not public" should literally mean "not public" and thus the feedback shouldn't be available without authorization/authentication

2. however, that screws up dashboards the UA folks are doing

So, we need to figure out some solution that satisfies both requirements.

	[:Cww]
	Comment 1 • 10 years ago

I think we need two levels of "not public". 

One major use for "not public" is actually to just not put stuff on the main input front page. I don't actually think we need high security for most of our data and it would be nice if the front page was just focused on the big products (especially since Loop/Heartbeat will slowly take over all of feedback otherwise).  API should still work and direct links to feedback should still work.

The other level is "fully private" which means no API, no front page and no direct links. This means that unauthenticated users don't know it exists. For building dashboards with this data, we assume that some part of it is sensitive so UA should use the DB access that we have and extract out the data that we want to display in a safe way.

	Robert (rrayborn, he/him)
	Comment 2 • 10 years ago

If we don't end up implementing cww's idea, I'd appreciate a few weeks buffer for us to emulate some of Input API's functionality before leaving. (We have other high priorities at the moment otherwise we could do this quickly).

	Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Comment 3 • 10 years ago

I'm game for Cww's idea.

Seems like we need to do two changes:

1. fix the response view (i.e. permalinks) so that they work regardless of whether the product is visible on the dashboard

2. add a new flag on products for public/private which if set to "private" causes the feedback to not show up anywhere without authentication/authorization: front page dashboard, response view, API, etc


Seems like the first one we need to fix pronto (it's an easy fix) and the second one we can push off until we need it since I think Cww is right in that none of the products we're collecting feedback for are super double-secret.

Does that sound right?

	[:Cww]
	Comment 4 • 10 years ago

Perfect.

	Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Comment 5 • 10 years ago

Grabbing this to fix the response view to not kick up a 404 when Product.on_dashboard is False.

Changing the scope of this bug. I'm going to kick the can on the rest of this bug until later.

	Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Comment 6 • 10 years ago

Fixing the response view in a PR: https://github.com/mozilla/fjord/pull/380

	Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Comment 7 • 10 years ago

PR 380 landed in https://github.com/mozilla/fjord/commit/5480c420c9e2db3d0b2071266b6113701fc7387e

I'll push it on Monday or possibly earlier if someone tells me to push it ASAP.

	Will Kahn-Greene [:willkg] ET needinfo? me Reporter
	Comment 8 • 9 years ago

Unassigning for now. I'm not working on it.

	Osmose [:osmose, :mkelly]
	Comment 9 • 7 years ago

The Input service has been decommissioned (see bug 1315316) and has been replaced by a redirect to an external vendor (SurveyGizmo). I'm bulk WONTFIXing Input bugs that do not appear to be relevant anymore.