`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.
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."
Going forward, if an app is unreviewed, we should 4xx the detail page for anonymous users.
Assignee: nobody → amckay
Whiteboard: [fireplace] → [fireplace] p=1
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
This likely still needs to happen.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
What needs to happen beyond the status being returned?
(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?
A user has to authenticate before getting the app details, the authentication does the ownership checks for that app.
I'm still not sure what needs to happen here.
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.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.