278639 - Developer CP - updated description appears before the extension version is approved

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[Alex Sirota (iosart)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Developer panel - submitting a new extension version for approval, asks for a
description of the new extension version. The description appears immediately,
before the version is approved. This can be confusing to the users - they see a
new description along with the old version. An easy workaround would be for me
to wait and update the description -after- the version is approved, but it would
be nice if every version had its own description.

A developer can wait until the extension is approved and only then update the
description. Maybe add a small warning in the entry form to warn the developer
that this is the behavior?

Reproducible: Always

Comment 1

[Wolf [:wolf]]

Not sure what to do here, but this is the behavior.. t_main is updated with a
new t_version record w/o passing through anything. 

Comment 2

[Giorgio Maone [:ma1]]

This is a database design issue.
We should really move the "Description" field from "main" table to "version".
For performance/convenience reasons (to be verified - less joins?) we *may* keep
main.Description and synchronize it with version.Description when approval is done.

Comment 3

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 4

[alanjstr]

*** Bug 343273 has been marked as a duplicate of this bug. ***

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

flig: this is fixed in the schema for Remora, right?

Comment 6

[Justin Scott [:fligtar]]

No, it's not. The description field is still part of the add-on, not the version, and I strongly recommend it stay that way, especially with localized descriptions in Remora. A per-version text field = Version Notes.

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I think that the description of an add-on should contain information about the features of the add-on, and should change over time as the features of the add-on change.  (As one example; there are others that are similar.)

If you don't think that, do you feel that an add-on author should have to watch the site until the version is approved, and then go and edit the description to match the latest?

An example: an IM add-on should list the networks it supports in its description, since that's an key element of its functionality.  When it adds support for MSN in a later version should have that full list of networks in its description, not just in version notes.  That this bug exists at all indicates to me that people expect description and version to be linked -- it certainly seems like the least surprising thing, given that the description is part of what's reviewed.

Comment 8

[Justin Scott [:fligtar]]

It's a slippery slope. Almost every field of the add-on could change with each version. A new version applies to another category. A new version has a new name. A new version adds a new author. A new version has a different homepage. A new version has different previews. So, really, the addons table should look like this:

+-----+----------------------------------------+
| id  | guid                                   |
+-----+----------------------------------------+
| 220 | {19503e42-ca3c-4c27-b1e2-9cdb2170ee34} |
| 722 | {73a6fe31-595d-460b-a920-fcc0f8843232} |
|  10 | {34274bf4-1d97-a289-e984-17e546307e4f} |
|  72 | {9f08cb5a-76b1-4bcf-aff9-90e1a5d60b1e} |
| 398 | {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} |
+-----+----------------------------------------+

right?

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

That proposal doesn't seem so bad to me.

As far as it being a slippery slope, I think that the description is the most pressing issue, though privacy policy might actually be more important now that I think about it.

Comment 10

[Justin Scott [:fligtar]]

This was discussed in our meeting today, and this is certainly an inconvenience, but we would prefer to make this table change after remora launches.

Comment 11

[Justin Scott [:fligtar]]

With the sandbox system, the description and file will appear in the sandbox at the same time since it doesn't have to undergo review. The only problem would be if someone adds a new version to a public add-on that has to be reviewed, it would be in the sandbox correctly but the new description would appear on the public side as well.

Comment 12

[Justin Scott [:fligtar]]

This is fixed in 3.5 as the add-on submission/update process has only one step of uploading the file. The developer does not update their description as part of the upload process, so there should be no expectation that changing the description or any other field would be connected with the new version.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED per comment 12 and my testing.