If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WONTFIX

Status

Marketplace
API
RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: cvan, Assigned: andym)

Tracking

Points:
---
Dependency tree / graph

Details

(Whiteboard: [fireplace] p=1)

(Reporter)

Description

5 years ago
`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.
(Reporter)

Comment 1

5 years ago
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

5 years ago
Going forward, if an app is unreviewed, we should 4xx the detail page for anonymous users.
(Assignee)

Updated

5 years ago
Assignee: nobody → amckay
Whiteboard: [fireplace] → [fireplace] p=1
(Assignee)

Comment 3

5 years ago
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.
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

5 years ago
This likely still needs to happen.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 5

5 years ago
What needs to happen beyond the status being returned?

Comment 6

5 years ago
(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?
(Assignee)

Comment 7

5 years ago
A user has to authenticate before getting the app details, the authentication does the ownership checks for that app.
Blocks: 859511
(Assignee)

Comment 8

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

Comment 9

5 years ago
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: 5 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.