853621 - [fireplace] `AppResource` should return `notifications` for pending apps based on ACL

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: API, defect)

Description

[Christopher Van Wiemeersch [:cvan]]

`AppResource` should return `notifications` based on https://github.com/mozilla/zamboni/blob/master/mkt/detail/templates/detail/protected_app.html#L67

As an anonymous user or authenticated-but-ordinary user: I should be able to see only an app whose status is amo.STATUS_PUBLIC (4).
As a developer or reviewer or admin: I should be able to see my/his/her/yo's app regardless of its status.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

I'm a developer and it's pending: http://cl.ly/image/1w091t0I0441
"This app is awaiting review. You will receive an email when the review is complete. Visit its Manage Status page to learn more."

I'm an anonymous user and it's pending: http://cl.ly/image/3U0b2v2b053X
"This app is awaiting review. Learn more."

Comment 2

[Matt Basta [:basta]]

Going forward, if an app is unreviewed, we should 4xx the detail page for anonymous users.

Comment 3

[Andy McKay]

Comment 2 already done (bug 833591). Comment 0 and comment 1. Status is already returned in the app details. The template logic for translating that can be done in fireplace, not in the API.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

This likely still needs to happen.

Comment 5

[Andy McKay]

What needs to happen beyond the status being returned?

Comment 6

[Potch [:potch]]

(In reply to Andy McKay [:andym] from comment #3)
> Comment 2 already done (bug 833591). Comment 0 and comment 1. Status is
> already returned in the app details. The template logic for translating that
> can be done in fireplace, not in the API.

Wouldn't that cause unreleased apps to leak out the API, if only the client-side is responsible for hiding them?

Comment 7

[Andy McKay]

A user has to authenticate before getting the app details, the authentication does the ownership checks for that app.

Comment 8

[Andy McKay]

I'm still not sure what needs to happen here.

Comment 9

[Matt Basta [:basta]]

I think we should identify the use cases and deal with them via HTTP response codes (when accessing the app resource directly, as the API currently does). An app that's not available to a user should either not be in a listing (i.e.: search/category) or it should have a flag on a case-by-case basis, which we can file bugs for when we cross that bridge.