Closed Bug 654096 Opened 9 years ago Closed 9 years ago
Reset version creation date when a new file is uploaded to an existing version
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: split off from bug 653490 Currently developers can add files to a version that's already in the queue, or that has reviewed files in it. As the creation date is set according to the first file in the version, and the queue is sorted by this date, then the version 'jumps' up the queue. What we want is the creation date of a version to be reset when a new file is added to a existing version. Reproducible: Always
(In reply to comment #0) > What we want is the creation date of a version to be reset when a new file is > added to a existing version. What you want is for the position in the queue to be determined by the age of the file, not the version, correct?
(In reply to comment #1) > What you want is for the position in the queue to be determined by the age of > the file, not the version, correct? The current behavior is that the version creation date doesn't change even if you delete all of its files and upload again. We want the position in the queue to be determined by the age of the newest file in the version. I think it's easier to reset the version creation date when a new file is added to it, but sorting the queue by the creation date of the most recent file is also a possible solution.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Priority: -- → P2
Hardware: x86 → All
Whiteboard: [required amo-editors]
Target Milestone: --- → 6.0.10
http://github.com/jbalogh/zamboni/commit/8fa260f It now calculates "Waiting Time" by file creation date; the version creation date isn't touched.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I added a new file to an add-on which was awaiting review. But the waiting time was not reset. STR: 1. Pick an add-on which is awaiting in review queue (Adhaadhoora123 2.0 with waiting time of 19 days) 2. Add a new platform-specific file @ https://addons.allizom.org/en-US/developers/addon/adhaadhoora129/versions/784139 expected behavior: Waiting time is reset actual behavior: Waiting time is no reset. It is still 19 days
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This works as planned (although possibly wrong, it's up to Jorge and co). The bug said to reset the creation date, which is only used for non-full-review queues. Full Review goes by nomination date. This means that if you created a file a year ago, and nominated it last week, the date would be last week. What we'd want for the full review queue would be: "Nomination Date, unless a file has been added since then, in which case we'd want Creation Date." This makes an already very complicated query even more complicated-- I'd want to reset the nomination date instead, I think. However, I didn't really think this fell under this bug. I'll leave it open for now, and see what jorgev and clouserw say.
That's a weird edge case. For nominations we assume that all files will be reviewed at once. Uploading a new file to a nomination that has already been reviewed is probably not contemplated anywhere. It should be rare enough to safely ignore, I think.
Okay, closing again.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
jorgev, If I add a new file to an add-on awaiting full review should the waiting time get reset?
No, it should only affect updates. The full review queue is sorted by nomination date, so uploading a new file to an add-on in that queue should not change its position.
checked that waiting time is reset on adding a new file to an add-on awaiting a) preliminary review b) pending update waiting time is not reset for add-ons awaiting full review.
Status: RESOLVED → VERIFIED
Reclassifying editor bugs and changing to a new whiteboard flag. Spam, spam, spam, spam...
Whiteboard: [required amo-editors] → [ReviewTeam]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.