875048 - Devhub doesn't differentiate between global app data and version data

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Developer Pages, defect, P4)

Description

[Chuck Harmston [:chuck]]

As, over time, we've begun accepting packaged apps, we've mixed together information on the devhub UI that should be stored globally per app and that which should be versioned.

We should inventory all data stored on Webapp, appropriately migrate data from the Webapp to the Version model, and develop and implement a better Devhub UI for managing versioned data.

This is potentially a blocker for #858314, since feature profiles should be versioned, though there is no logical place to do so.

Comment 1

[Chuck Harmston [:chuck]]

By my count, the following data should be versioned and editable in devhub on a per-version basis:

Platform compatibility
Region compatibility
App icons
Screenshots/videos
Feature profile data
Information prepopulated from the manifest (description, etc...potentially even the name?)

This may not be an exhaustive list.

Comment 2

[Wil Clouser [:clouserw]]

What is critical for bug 858314?  I think you want a place in the UI to show the checkboxes, right?  Is that it?

Comment 3

[Chuck Harmston [:chuck]]

On a per-version basis, yes.

Comment 4

[Wil Clouser [:clouserw]]

Attachment: UX

Attaching Bram's UX for modifying per-version data

Comment 5

[Bram Pitoyo [:bram]]

Pasting my notes from bug 875063 comment 7 about the attachment:

In this series of mockups, I proposed three ideas:

1. Editing features in a version is an activity that, on user’s mind, go hand-in-hand with uploading a new version

2. There are many things that can be edited when uploading a new version. Feature is one of them. The other ones are addressed in bug 875048 comment 1, like:
  * Description, summary, categories, websites, emails
  * Icons, screenshots and videos
  * Payment and country availability

3. The upload new version experience needn’t be created from scratch



The solution I proposed has two sides:

1. On one hand, user should be able to edit the feature list of new version, /before/ the new version goes into the reviewer’s queue

2. On the other hand, user should also be able to edit features on both new and existing versions, /after/ the new version goes into the queue. Plus, editing needs to be available during the waiting period, where the existing version is already published, but the new version is still in the queue


The attachment addresses solution #1 using an interface that’s practically similar to our existing app submission flow.

I haven’t thought of how we would go about #2 yet, but am fairly confident that we can use existing pages and UI elements to achieve it.

Comment 6

[Bram Pitoyo [:bram]]

Attachment: publishing packaged app w/ multiple versions - 02

The mockup has been updated with the addition of two pages that describes how user can edit a version that’s just been submitted.

The way it works is pretty simple. After a new version has been submitted, it will appear on the “Version & Publishing” page. On the side of the new version information is an “Edit” button that performs the said function.

The “Edit” button will appear as long as the new version is not yet published. When published, editing will be done by using the “Details” page.

This way, user is able to edit both the existing version and the newly submitted one, thus addressing the problem I mentioned in the last paragraph of comment 5.

Comment 7

[Chuck Harmston [:chuck]]

NB: bug 877284 comment 2