246945 - [META] autodetect more info from uploaded item

Status: RESOLVED FIXED

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

Description

[alanjstr]

When adding an update to an existing theme or extension, it should be keyed off
the GUID, so picking from the dropdown is unneccessary.  It could just be
o New Item
o Update to an Existing Item

What would happen if I picked the wrong item?  I don't want to know.  The only
issue would be things without a GUID.  And I think we should make Seamonkey
extensions have an install.rdf, even if the installer doesn't use it.  That
leaves plugins, but they're not jars or xpis, usually, and they're a future
consideration.

Comment 1

[alanjstr]

Actually, the radio button isn't really necessary, since either the GUID exists
or not.

Comment 2

[Wolf [:wolf]]

Uh, why should we break Mozilla Suite extension support by arbitrarily requiring
a mythical GUID? and why should we expect Mozilla Suite authors to support this
concept?  
Also, many of the plugins this site would be ideal to support, would be XPIs, if
the whitelisting doesn't kill them off. as it's the easiest method for end-users
to install them through.

If you picked the wrong item the GUID would conflict and be rejected, also,
what's to stop somebody from adding an extension or theme version to somebody
elses extension or theme? it's not like the manifest is providing valid author
data that's in a form usable to update... the dropdown helps guide that
selection process and actually ensures the t_main record used is correct. as
long as the provided GUID and known GUID are alike. 

The radio button is used to determine mode, and condense code, by defining two
paths of things that need to be done, some of which are common. It's not hugely
required, but it does make things a bit more obvious what's going on, rather
than relying on mythical code.

My current opinion on this bug is either invalid or wontfix.

Comment 3

[alanjstr]

The GUID would be for supporting the site.  It won't break compatibility with
anything.

What if someone uses someone else's GUID?  How would the update service know
which one it is?  

Comment 4

[Wolf [:wolf]]

(In reply to comment #3)
> What if someone uses someone else's GUID?  How would the update service know
> which one it is?  

in update mode, an author check is perfromed between the GUID's author and the
current logged in user.. 

in new mode, it's just plain rejected.

Comment 5

[alanjstr]

This is a request for an enhancement.  Please don't think of it in terms of the
code, but in the user experience.

Comment 6

[Wolf [:wolf]]

Already discussed.

Comment 7

[Wolf [:wolf]]

This is per-design specifications.. and is 100% intentionally designed this way.

--> WONTFIX.

Comment 8

[alanjstr]

What's to prevent another author from making the same mistake as I did and
choose the New radio button but the right thing from the dropdown?  We can
detect if something is New or Existing already with a simple query.  If you're
worried about someone adding a version to which they don't own, that's a backend
security bug and shouldn't force them to use the UI like that.

What if they selected the Existing radio button but it was really a new
extension? If you're thinking in terms of the code associated, don't.  And if
you're limiting the vision to merely a spec, then you're not thinking like a user.

Comment 9

[Wolf [:wolf]]

Mind explaining yourself? this bug is still a wontfix.

Comment 10

[alanjstr]

This makes the user experience much better.

    * Has install.rdf: Check for existing GUID match
          o New GUID
                + Ask whether theme or extension, etc (could be guessed from dir
structure)
          o Existing GUID
                + Check whether logged in user has permission for that GUID
                + Check whether that version is already uploaded
    * No install.rdf
          o Have user pick from dropdown of New Theme, New Extension, and
updates to which they have permission (best guess from install.js and chrome.rdf?)

Comment 11

[alanjstr]

<ben> you can guess whether it's a theme or an extension by looking for
em:internalName on the install.rdf 

Comment 12

[Tristor]

So, your problem is with the radio button, right?  Would it help if it was
changed to checkboxes instead?  I mean, I hate radio buttons too, they are so
naughty :D

Comment 13

[alanjstr]

Attachment: Old and New GUI

Comment 14

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

This would be useful.

Comment 15

[Wolf [:wolf]]

heh, this bug is basically a game. Far as I'm concerned, it remains a wontfix,
it was wontfixed when it was assigned to me, and so far, there's been no comment
explaining why it was reopened and reassigned.

This bug suggests taking a rough guess system and making it completely
unpredictable. (Guessing paths (?!?) to figure out if it'll land in Extensions
or Themes). Pretty much everything here will end up needing to be confirmed
anyway. so what's the point?

Comment 16

[alanjstr]

The only real new thing is to automatically detect whether it is new or
existing.   If new, then we know how to detect whether it is a theme or
extension based on the existance of em:internalName.  All detection is based on
install.rdf's contents.

References I'm using...
http://kb.mozillazine.org/index.phtml?title=Dev_:_Extensions_:_install.rdf
http://www.mozilla.org/projects/firefox/extensions/update.html

Mozilla Suite is moving to toolkit, so install.rdf will be supported there
(based on a comment by Doron).

Check to see if uploaded file is openable with zip
Check to see if it contains an install.rdf
Check for valid XML
Check for valid GUID
Check to see if GUID is in DB /* new thing */
  If in DB, check to see if logged in user has security clearance
Validate the contents of install.rdf for 
  Required elements
    id, name, version (major.minor.release.build[+]), description, creator
Validate target applications:
  Must have at least one known target (FX, TB, 1.x)
  minVer and maxVer must be within known ranges

If new
  Detect whether this is a theme or extension based on whether it contains
em:internalName

If old
  Does this version for the combination of OS and minVer maxVer already exist

Comment 17

[alanjstr]

TBD after the other bugs are fixed like Seamonkey detection.

Comment 18

[alanjstr]

This meta bug covers parsing install.rdf and getting all the useful information
out of it.

Comment 19

[Wolf [:wolf]]

Bulk Moving Developer Control Panel bugs to new component.
(Filter: massdevcpspam)

Comment 20

[Cameron]

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

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

Filtermeplzkthx

Comment 21

[Justin Scott [:fligtar]]

Brief summary of this process in Remora: there is only one submission form. The uploaded item is automatically detected to be an extension, theme, or dictionary. The GUID is read and if it is in the database and the user is an author, it's an update. If it's in the database and the user isn't an author, permission denied. If it's not in the database, it's a new add-on.