« Back to Remora Main

Schema

• Schema Diagram
• remora.sql
• Schema Birthing Photo
• linux8 PHPMyAdmin

Notes

password field

Should the users table have a password field? Fligtar

Yes. That was an accidental omission. Morgamic

canned responses/auditing

What about a table for canned review responses (if we still want them) and a table for auditing all developer/review/admin actions? Fligtar

changes?

• addons.approvalnotes -> versions.approvalnotes?
• versions.modifid -> versions.modified
• files.platform_id -> bug 279235 - if this bug is to be implemented, we need a files_platforms or versions_platforms table

Fligtar 18:43, 28 August 2006 (PDT)

hardcoding addontype ids

I am hardcoding the addontype ids as follows. We can rename the actual types to whatever, but they have to stay with the associated id.

INSERT INTO `addontypes` (`id`, `name`, `created`, `modified`) VALUES (1, 'Extension', '2006-08-21 23:53:19', '2006-08-21 23:53:19'),
(2, 'Theme', '2006-08-21 23:53:24', '2006-08-21 23:53:24'),
(3, 'Dictionary', '2006-08-21 23:53:30', '2006-08-21 23:53:30'),
(4, 'Search Plugin', '2006-08-21 23:53:36', '2006-08-21 23:53:36'),
(5, 'Language Pack (Application)', '2006-08-21 23:53:58', '2006-08-21 23:53:58'),
(6, 'Language Pack (Add-on)', '2006-08-21 23:54:09', '2006-08-21 23:54:09');

more changes

versions.dateadded and versions.dateupdated can be removed, as created and modified serve that purpose

applications_versions.created and modified can be removed, as cake does not take into account any additional fields in HABTM tables (including created and modified). I haven't looked at the other lookup tables, but additional fields can be removed there as well. Fligtar 11:56, 27 September 2006 (PDT)

versions.approval

Currently, the schema has a versions.approved int field, but because a single version can have multiple files associated with it (for different platforms), we should have a files.approved field for the individual files.

So, the logic for displaying the public addon page (using the approval status defines from bootstrap) would be something like:

if (versions.approved == APPROVAL_GRANTED) {
	showVersion();

	foreach (files as file) {
		if (file.approved == APPROVAL_GRANTED) {
			showFile(file.id);
		}
	}
}

Example 1: User uploads 2 files (Linux and Windows) at the same time when creating the new version. As soon as one of these is approved, that file.approved is set to APPROVAL_GRANTED, and so is versions.approved. The new version will now be displayed.

Do we want to add something to allow the author to specify that the version should only be public once all files associated with it have been approved? Note that this would mean that example 2 would cause problems:

Example 2: User uploads Windows only platform when creating a version. That file is approved, so file.approved and versions.approved are set to APPROVAL_GRANTED. A week later, the author uploads a Linux platform with the same version number, so it is added to that version, but not displayed publicly until it is approved.

If we were to allow the author to specify that the version should only display when all files are approved, the previously displayed version would become un-displayed once the author uploads that new file that's not yet been approved.

Note that this assumes the decision made earlier today that application compatibility must be on a per-version basis, so if you say Windows works with Firefox 2.0, Linux must also.

The above is what we discussed earlier, but now for the confusing part. We don't really need versions.approval to fill the position described above. The above pseudocode could just as easily be accomplished with:

foreach (files as file) {
	if (file.approved == APPROVAL_GRANTED) {
		showVersion();
		showFile(file.id);
	}
}

So maybe the versions.approval field should be used to facilitate the above mentioned setting about waiting until all versions are approved? So, if versions.approval = 0, we'll loop through the files as shown a few lines above and display accordingly. If versions.approval = 1, that means they only want it displayed if all versions are approved, so process that to determine whether the version should be displayed. If we did this, we'd probably want to call it something else, like versions.allfilesrequired.

I don't think versions.approved should be (or could be easily) used as an approval for the metadata exclusively, as I think shaver was mentioning. If something is wrong with the metadata, you place the file in the new "Held" status for the author to correct the metadata and then it will jump to the top of the queue for re-approval.

Another aspect of this is the migration script. I looked at the script but couldn't really tell if it does this currently but I don't think it does. Since we will be using multiple files for a single version, existing addons should be copied over like that. I think the way v1/v2 does it is it just creates a second version row for the additional files. So I think the migration script would need to create a separate file row for each old version row that has the same addon id and version number and different platform.

So, ummm... yeah. Fligtar 22:47, 4 October 2006 (PDT)