NotExportedFromLaunchpad error on user XPI upload
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
A user complains that after uploading an XPI file (as a user upload, not a published one) the import is rejected with "File was not exported from Launchpad."
The reason is that for user uploads, we require the date at which a file was exported from Launchpad so that we can check for conflicting changes (as well as, I suppose, files that might inconsiderately overwrite translations in Launchpad with unrelated ones). But in an XPI file we have no timestamp to represent the Launchpad export date, and so a user upload always fails.
If we wanted to do a similar check in Launchpad, we currently only have two relevant dates to use: "now" and a last-change time we could possibly derive from file metadata inside the XPI archive. The latter would be unreliable (because of timezones and perhaps clock skew) and arbitrary (because there's no reason to believe the author checked for conflicts with Launchpad just at that moment). We could use "now," which effectively disables the check and lets an import overwrite changes in Launchpad. But translations that were unchanged from a very old version of the XPI would appear as "changed" to Launchpad.
Other options would be:
* Sneak our custom timestamp header field into the RDF when converting XPIPO to XPI.
* Disallow XPI user uploads, and maybe support XPIPO instead.
The XPI file in question is at http://
How urgent is this seeing that we currently don't use Firefox translations anyway? I tend to disallow these kind of uploads all together. At UDS-M we agreed on a different workflow instead of improving xpi support: /blueprints. launchpad. net/ubuntu/ +spec/desktop- maverick- native- xpi-lp- export
https:/