summaryrefslogtreecommitdiff
path: root/patchwork/migrations
Commit message (Collapse)AuthorAge
* models: Validate Project.linkname does not contain forward slashThomas Bracht Laumann Jespersen2020-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | I started by creating a project that contained a forward slash (importing patches from https://lists.sr.ht/~sircmpwn/sr.ht-dev/) and it fails to render the "projects" main page. The specific error reads: NoReverseMatch at / Reverse for 'patch-list' with keyword arguments '{'project_id': 'foo/bar'}' not found. 1 pattern(s) tried: ['project/(?P<project_id>[^/]+)/list/$'] which appears to explicitly disallow forward slashes. So I think it makes sense to validate that project linkname doesn't contain forward slahes. This implementation uses the validate_unicode_slug validator instead of just rejecting inputs that contain forward slashes. Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz> Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #380
* migrations: Moved squashed migrationStephen Finucane2020-04-26
| | | | | | | | This should have been in the 'patchwork/migrations' directory, not 'migrations. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: 9bb5caec ("migrations: Squash 0001 to 0040")
* migrations: Resolve issues with other DB backends for 0042, 0043Stephen Finucane2020-04-26
| | | | | | | | | | 0042 was using MySQL-specific SQL to delete entries in the 'patchwork_comment' table that were associated with entries in the 'patchwork_coverletter' table, while 0043 only considered MySQL and PostgrSQL when attempting to copy fields from 'patchwork_patch' to 'patchwork_submission'. Both issues are resolved. Signed-off-by: Stephen Finucane <stephen@that.guru>
* models: Merge 'Patch' and 'Submission'Stephen Finucane2020-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oh, the follies of youth. Time to undo the damage of 2.0.0, specifically commit 86172ccc16, which split Patch into two separate models using concrete inheritance. As noted previously, this introduced a large number of unavoidable JOINs across large tables and the performance impacts these introduce are blocking other features we want, such as improved tagging functionality. To combine these two models, we must do the following: - Update any references to the 'Patch' model to point to the 'Submission' model instead - Move everything from 'Patch' to 'Submission', including both fields and options - Delete the 'Patch' model - Rename the 'Submission' model to 'Patch' With this change, our model "hierarchy" goes from: Submission Patch PatchComment Cover CoverComment To a nice, flat: Patch PatchComment Cover CoverComment I expect this migration to be intensive, particularly for MySQL users who will see their entire tables rewritten. Unfortunately I don't see any way to resolve this in an easier manner. Signed-off-by: Stephen Finucane <stephen@that.guru>
* models: Split 'CoverLetter' from 'Submission'Stephen Finucane2020-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to get rid of the split between 'Patch' and 'Submission' because of the cost of using JOINs basically everywhere we use 'Patch'. Before we do that, we need to move the other users of 'Submission' to other models and other models that rely on these users sharing the common 'Submission' base. For the former, there is only one user, 'CoverLetter', while for the latter there is only the 'Comment' model. As a result, we must do the following: - Create a new 'Cover' model - Create a new 'CoverComment' model - Move everything from 'CoverLetter' to 'Cover' and all entries associated with a 'CoverLetter' from 'Comment' to 'CoverComment' - Delete the 'CoverLetter' model - Rename the 'Comment' model to 'PatchComment' This means our model "hierarchy" goes from: Submission Patch CoverLetter Comment To: Submission Patch PatchComment Cover CoverComment A future change will flatten the 'Submission' and 'Patch' model. Note that this actually highlighted a bug in Django, which has since been reported upstream [1]. As noted there, the issue stems from MySQL's refusal to remove an index from a foreign key when DB constraints are used and the workaround is to remove the foreign key constraint before altering the indexes and then re-add the constraint after. [1] https://code.djangoproject.com/ticket/31335 Signed-off-by: Stephen Finucane <stephen@that.guru>
* Remove __future__ importsStephen Finucane2020-04-09
| | | | | | | | All of these are defaults in Python 3 [1]. [1] https://docs.python.org/3.6/library/__future__.html Signed-off-by: Stephen Finucane <stephen@that.guru>
* migrations: Add the Python 3 patchStephen Finucane2020-04-08
| | | | | | | Django has wanted this for a long time. It doesn't seem to do anything but it keeps Django happy so... Signed-off-by: Stephen Finucane <stephen@that.guru>
* trivial: Feed 'patchwork.migrations' through blackStephen Finucane2020-03-19
| | | | | | | Include migrations in the flake8 checks, which should catch some simple undefined variables errors. Signed-off-by: Stephen Finucane <stephen@that.guru>
* models, templates: Add patch relationsMete Polat2020-03-16
| | | | | | | | | | | | | | | | Introduces the ability to add relations between patches. Relations are displayed in the details page of a patch under 'Related'. Related patches located in another projects can be viewed as well. Changes to relations are tracked in events. Currently the display of this is very bare in the API but that will be fixed in a subsequent patch: this is the minimum required to avoid throwing errors when you view the events feed. Signed-off-by: Mete Polat <metepolat2000@gmail.com> [dja: address some review comments from Stephen, add an admin view, move to using Events, misc tidy-ups.] Signed-off-by: Daniel Axtens <dja@axtens.net>
* migrations: Don't attempt to rehome patchesStephen Finucane2020-03-11
| | | | | | | | | | | | | | | | | Migration 0039 attempts to move patches that have ended up in an arbitrary series due to race conditions into the correct series. However, there are a number of race conditions that can occur here that make this particularly tricky to do. Given that series are really just arbitary metadata, it's not really necessary to do this...so don't. Instead, just delete the series references that identical message IDs and below to the same project, allowing us to add the uniqueness constraint and prevent the issue bubbling up in the future. This means we're still left with orphaned series but these could be fixed manually, if necessary. Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Ali Alnubani <alialnu@mellanox.com> Closes: #340
* models: Use database constraints to prevent split SeriesStephen Finucane2019-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, the 'SeriesReference' object has a unique constraint on the two fields it has, 'series', which is a foreign key to 'Series', and 'msgid'. This is the wrong constraint. What we actually want to enforce is that a patch, cover letter or comment is referenced by a single series, or rather a single series per project the submission appears on. As such, we should be enforcing uniqueness on the msgid and the project that the patch, cover letter or comment belongs to. This requires adding a new field to the object, 'project', since it's not possible to do something like the following: unique_together = [('msgid', 'series__project')] This is detailed here [1]. In addition, the migration needs a precursor migration step to merge any broken series. [1] https://stackoverflow.com/a/4440189/613428 Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #241 Cc: Daniel Axtens <dja@axtens.net> Cc: Petr Vorel <petr.vorel@gmail.com>
* models: Add State.slug fieldStephen Finucane2019-12-27
| | | | | | | | | | | | | This reduces a lot of the tech debt we had built up around this. This field is populated from a slugified representation of State.name and has a uniqueness constraint. As a result, we also need to a uniqueness constraint to the State.name field. This shouldn't be an issue and probably should have been used from day one. Note that there is no REST API impact for this since we've been using state slugs all along. Signed-off-by: Stephen Finucane <stephen@that.guru>
* models.Event: Add the user responsible for the eventJohan Herland2019-12-01
| | | | | | | | | This allows using the events as a kind of audit log, to see how a patch came to its current state/delegate. Signed-off-by: Johan Herland <johan@herland.net> Reviewed-by: Stephen Finucane <stephen@that.guru> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
* migrations: Correct 'unique_together' order in '0015'Stephen Finucane2019-08-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was resulting in exceptions like the following when used with MySQL 8.0: Traceback (most recent call last): File "../patchwork/manage.py", line 11, in <module> execute_from_command_line(sys.argv) ... File "../.tox/py27-django111/lib/python2.7/site-packages/django/db/backends/mysql/schema.py", line 88, in _delete_composed_index return super(DatabaseSchemaEditor, self)._delete_composed_index(model, fields, *args) File "../.tox/py27-django111/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 394, in _delete_composed_index ", ".join(columns), ValueError: Found wrong number (0) of constraints for patchwork_seriespatch(series_id, number) This error was being raised by the following lines in the 0033 migration: migrations.AlterUniqueTogether( name='seriespatch', unique_together=set([]), ) It appears that this is because of a mismatch between the order of fields in a 'unique_together' constraint [1]. Correct the order in the original migration and see the issue disappear. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: d67d859f40f ("models: Add 'Series' model")
* models: Add commit_url_format to ProjectMichael Ellerman2019-08-30
| | | | | | | | | | | | Add a new field to Project, commit_url_format, which specifies a format string that can be used to generate a link to a particular commit for a project. This is used in the display of a patch, to render the patch's commit as a clickable link back to the commit on the SCM website. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Daniel Axtens <dja@axtens.net>
* models: Add list archive lookupAndrew Donnellan2019-08-22
| | | | | | | | | | | | | | | | Add a list_archive_url_format field to Project, which will contain the address of a Message-ID redirector, e.g. "https://lore.kernel.org/r/{}". Add a list_archive_url property to Submission and Comment, to generate an archive lookup URL based on the Message-ID. We will use this to display links to mailing list archives. Also add the new field to the default patchwork project fixture. Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net>
* models, templates: Add project list archive URL fieldAndrew Donnellan2019-08-22
| | | | | | | | | | Add a field to link to a project's mailing list archive, and display it on the project info page. Add the new field to the patchwork project in the supplied example fixture. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net>
* models: Convert Series-Patch relationship to 1:NStephen Finucane2018-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Late in the development of the series feature, it was decided that there were advantages to allowing an N:M relationship between series and patches. This would allow us to do things like create complete series where a sole vN patch was sent to a list rather than the full series. After some time using series in the wild, it's apparent that such features are very difficult to implement correctly and will likely never be implemented. As such, it's time to start cleaning up the mess, paving the way for things like an improved tagging feature. There are some significant changes to the model required: - models.py, migrations/0027, migrations/0028, migrations/0029 The migrations make the following changes: 1. - Add 'Patch.series_alt' and 'Patch.number' fields. 2. - Populate the 'Patch.series_alt' and 'Patch.number' fields from their 'SeriesPatch' equivalents. 3. - Remove the 'SeriesPatch' model. - Rename 'Patch.series_alt' to 'Patch.series'. - Change 'Series.cover_letter' to a 'OneToOneField' since a cover letter can no longer be assigned to multiple series. Note that the migrations have to be split into multiple parts as the combined migration raises an OperationalError as below. (1072, "Key column 'series_alt_id' doesn't exist in table") This is due to Django's penchant for creating indexes for newly created fields, as noted here: https://stackoverflow.com/q/35158530/ Aside from the model changes, there are numerous other changes required: - admin.py Reflect model changes for the 'PatchInline' inline used by 'SeriesAdmin' - api/cover.py, api/patch.py Update the 'series' field for the cover letter and patch resources to reflect the model changes. A 'to_representation' function is added in both cases to post-process this field and make it look like a list again. This is necessary to avoid breaking clients. - parser.py Update to reflect the replacement of 'SeriesPatch' with 'Patch'. - signals.py Update to filter on changes to 'Patch' instead of 'SeriesPatch'. This requires some reworking due to how we set these fields now, as we can no longer receive on 'post_save' signals for 'SeriesPatch' and must instead watch for 'pre_save' on 'Patch', which is what we do for delegate and state changes on same. - templates/patchwork/*.html Remove logic that handled multiple series in favour of the (simpler) single series logic. - tests/* Modify the 'create_series_patch' helper to reflect the removal of the 'SeriesPatch' model. This entire helper will be removed in a future change. Improve some tests to cover edge cases that were highlighted during development Unfortunately, all of the above changes must go in at the same time, otherwise we end up with either (a) broken views, API etc. or (b) split brain because we need to keep the new single-series fields alongside the older multi-series fields and models while we rework the views. It's unfortunate but there's not much to be done here. Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Daniel Axtens <dja@axtens.net>
* Add covering index to patchwork_submissions for /list/ queriesStewart Smith2018-09-10
| | | | | | | | | | | This gets PostgreSQL to generate *much* better query plans, gaining us about two orders of magnitude in performance on the /list/ query for the worst state project on the patchwork.ozlabs.org instance (qemu-devel). Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [stephenfin: Regenerate migrations per addition of 0027 in earlier patch] Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add covering index for /list/ queryStewart Smith2018-09-10
| | | | | | | | | | | | | | | | | | | | | | | In constructing the list of patches for a project, there are two main queries that are executed: 1) get a count() of how many patches there are 2) Get the page of results being displayed In a test dataset of ~11500 LKML patches and ~4000 others, the existing code would take around 585ms and 858ms with a cold cache and 28ms and 198ms for a warm cache. By adding a covering index, we get down to 4ms and 255ms for a cold cache, and 4ms and 143ms for a warm cache! Additionally, when there's a lot of archived or accepted patches (I used ~11000 archived out of the 15000 total in my test set) the query time goes from 28ms and 72ms down to 2ms and 33-40ms! Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [stephenfin: Regenerate migrations per addition of 0027 in earlier patch] Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add index for patchwork_comment (submission_id,date)Stewart Smith2018-09-06
| | | | | | | | | | | | | | | | | | | This (at least theoretically) should speed up displaying comments on patches/cover letters. It's an index that will return rows in-order for the query that we always do ("give me the comments on this submission in date order"), rather than having to have the database server do a sort for us. I haven't been able to benchmark something locally that shows this is an actual improvement, but I don't have as large data set as various production instances. The query plan does look a bit nicer though. Although the benefit of index maintenance versus how long it takes to sort things is a good question. Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [stephenfin: Regenerate migrations per addition of 0027 in earlier patch] Signed-off-by: Stephen Finucane <stephen@that.guru>
* Improve patch listing performance (~3x)Stewart Smith2018-08-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's two main bits that are really expensive when composing the list of patches for a project: the query getting the list, and the query finding the series for each patch. If we look at the query getting the list, it gets a lot of unnecessary fields such as 'headers' and 'content', even though we tell Django not to. It turns out that Django seems to ignore the Submission relationship and I have no idea how to force it to ignore that thing (defer doesn't work) but if we go only, then it works okay. From my import of ~8000 messages for a few projects, my laptop query time (MySQL, as setup by whatever the docker-compose things do) goes from: http://localhost:8000/project/linux-kernel/list/ FROM: 342ms SQL queries cold cache, 268ms warm cache TO: 118ms SQL queries cold cache, 88ms warm cache Which is... non trivial to say the least. The big jump is the patches.only change, and the removal of ordering on the patchseries takes a further 10ms off. For some strange reason, it seems rather hard to tell Django that you don't care what order the results come back in for that query (if we do, then the db server has to do a sort rather than just return each row) Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [stephenfin: Add missing migration that had been squashed into a later migration] Signed-off-by: Stephen Finucane <stephen@that.guru>
* Remove support for Django 1.8, 1.9, 1.10Stephen Finucane2018-08-26
| | | | | | | | | | | | | | These are now all EOL and Debian Testing supports Django 1.11 (LTS). We can and should drop them. This change does not remove the many compat wrappers. These will be removed separately (there are a lot of them). This leaves 1.11 as the only supported version. This will be remedied shortly with the inclusion of Django 2.0 support. Signed-off-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* models: Add a backreference for a user's bundlesStephen Finucane2018-04-25
| | | | | | This is more intuitive. Signed-off-by: Stephen Finucane <stephen@that.guru>
* migrations: Add missing migrationStephen Finucane2018-03-25
| | | | | | | Add a migration that was missed in an earlier change. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: 0f25d8a15 ("Add validation for regular expressions")
* Fix slow Patch counting queryDaniel Axtens2018-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stephen Rothwell noticed (way back in September - sorry Stephen!) that the following query is really slow on OzLabs: SELECT COUNT(*) AS "__count" FROM "patchwork_patch" INNER JOIN "patchwork_submission" ON ("patchwork_patch"."submission_ptr_id" = "patchwork_submission"."id") WHERE ("patchwork_submission"."project_id" = 14 AND "patchwork_patch"."state_id" IN (SELECT U0."id" AS Col1 FROM "patchwork_state" U0 WHERE U0."action_required" = true ORDER BY U0."ordering" ASC)); I think this is really slow because we have to join the patch and submission table to get the project id, which we need to filter the patches. Duplicate the project id in the patch table itself, which allows us to avoid the JOIN. The new query reads as: SELECT COUNT(*) AS "__count" FROM "patchwork_patch" WHERE ("patchwork_patch"."patch_project_id" = 1 AND "patchwork_patch"."state_id" IN (SELECT U0."id" AS Col1 FROM "patchwork_state" U0 WHERE U0."action_required" = true ORDER BY U0."ordering" ASC)); Very simple testing on a small, artifical Postgres instance (3 projects, 102711 patches), shows speed gains of ~1.5-5x for this query. Looking at Postgres' cost estimates (EXPLAIN) of the first query vs the second query, we see a ~1.75x improvement there too. I suspect the gains will be bigger on OzLabs. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Avoid timezone confusionVeronika Kabatova2018-03-08
| | | | | | | | | | | | | | | | | | | | | | | Patchwork saves patches, comments etc with UTC timezone and reports this time when opening the patch details. However, internally generated processes such as events are reported with the instance's local time. There's nothing wrong with that and making PW timezone-aware would add useless complexity, but in a world-wide collaboration a lot of confusion may arise as the timezone is not reported at all. Instance's local time might be very different from the local time of CI integrating with PW, which is different from the local time of person dealing with it etc. Use UTC everywhere by default instead of UTC for sumbissions and local timezone for internally generated events (which is not reported). Signed-off-by: Veronika Kabatova <vkabatov@redhat.com> [dja: - squash 2 patches: https://patchwork.ozlabs.org/patch/876744/ https://patchwork.ozlabs.org/patch/877815/ - minor changes to both patches - rejig order of migrations and adjust wording: "happened sooner" -> "happened earlier"] Tested-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Implement list filteringVeronika Kabatova2018-02-27
| | | | | | | | | | | | | | | Sometimes, multiple projects reside at the same mailing list. So far, Patchwork only allowed a single project per mailing list, which made it impossible for these projects to use Patchwork (unless they did some dirty hacks). Add a new property `subject_match` to projects and implement filtering on (list_id, subject_match) match instead of solely list_id. Instance admin can specify a regex on a per-project basis when the project is created. Signed-off-by: Veronika Kabatova <vkabatov@redhat.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
* migrations: Add missing Series.Meta, Patch.Meta changesStephen Finucane2018-02-13
| | | | | | | | These were missed in previous patches. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: 8585ea5af ("models: Use 'base_manager_name'") Fixes: ed7328fdb ("models: Series plural name is Series")
* models, templatetags: Make tag count column in patch list optional per tagAndrew Donnellan2018-01-04
| | | | | | | | | | | | | | | Add a field, show_column, to the Tag model to determine whether the tag gets a tag count column in the patch list view. This allows the creation of tags that will be collated when generating mboxes but won't take up space in the patch list. show_column will default to True to maintain the current behaviour by default. Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Closes: #142 ("Ability to add tags that don't also have a column in the UI") Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
* migrations: Mark 'RunPython' blocks as non-atomicStephen Finucane2017-12-03
| | | | | | | | | | | This appears to be required to run migrations on MySQL backend. Without this, the following error messages are propagated: Executing DDL statements while in a transaction on databases that can't perform a rollback is prohibited. Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Daniel Axtens <dja@axtens.net>
* migrations: Mark '0016_series_project' as non-atomicStephen Finucane2017-06-14
| | | | | | | | | This should resolve migration issues arising from PostgreSQL's inability to mix data and schema migrations in a single transaction. Signed-off-by: Stephen Finucane <stephen@that.guru> Acked-by: Aaron Conole <aconole@bytheb.org> Closes-bug: #104
* migrations: Explicitly set 'on_delete'Stephen Finucane2017-05-18
| | | | | | This raises warnings for Django 1.9 and will be mandatory in Django 2.0. Signed-off-by: Stephen Finucane <stephen@that.guru>
* 'mpe mode': click to copy patch IDsDaniel Axtens2017-04-15
| | | | | | | | | | | | | If 'Show Patch IDs' is turned on in settings, add an extra column to the patch list, with buttons showing the patch IDs. The buttons copy the patch IDs to the clipboard. JavaScript inspired by https://github.com/Triforcey/clip-j and many many StackOverflow answers. Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephen@that.guru>
* models: Add 'Event' modelStephen Finucane2017-03-01
| | | | | | | | Events record Patch-related things like initial creation, state transitions, delegation assigning etc. Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Daniel Axtens <dja@axtens.net>
* Improve documentation of delegation rulesStephen Finucane2017-02-08
| | | | | | | | | | | | | | Per feedback from FOSDEM, this is still confusing some people. Clarify things. You might think we could just strip of the offending prefixes but that might not always be the thing to do. Other VCSs don't include these prefixes and both 'a' and 'b' are valid folder names. The risk of false positives might be small, but it's enough to discourage us from doing this. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Thomas Monjalon <thomas.monjalon@6wind.com>
* Fix series.project migration logicAndy Doan2017-01-26
| | | | | | | | | | | | | | | | The migration logic seems slightly off for 2 reasons: 1) If you already have series objects in your database, then adding a non-nullable foreign key to projects will fail. 2) This may just be a remnant of my development database, but I had series entries with no patches. I think part #1 is *required*. I'm not totally sure about #2, but it seems safe. Signed-off-by: Andy Doan <andy.doan@linaro.org> Reviewed-by: Stephen Finucane <stephen@that.guru>
* migrations: Don't use 'noop'Stephen Finucane2017-01-23
| | | | | | | | | The 'noop' operation was introduced in Django 1.8, meaning this operation won't work on Django 1.7. Travis caught this, though I don't know how it was missed locally. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: e3cbe493 ("models: Add 'project' field to Series")
* models: Add 'project' field to SeriesStephen Finucane2017-01-22
| | | | | | | | | | | | This is helpful for filtering. We use RunPython because folks are likely to have few if any Series objects existing yet. In addition, we update the unique constraints for SeriesReference as it's now possible to handle messages with duplicate message IDs. The update is included in parser to ensure this applies immediately. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Andy Doan <andy.doan@linaro.org>
* models: Add 'Series' modelStephen Finucane2016-10-31
| | | | | | | | | | | Add a series model. This model is expected to act like a collection for patches, similar to bundles but thread-orientated. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Andy Doan <andy.doan@linaro.org> Reviewed-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Russell Currey <ruscur@russell.cc>
* models: Remove 'UserProfile.primary_project'Stephen Finucane2016-10-10
| | | | | | | This field was unused and has been for a long time (pre-0.9.0). Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
* Convert RunSQL migration commands from list to stringsDaniel Axtens2016-08-21
| | | | | | | | | | | | | The ability to use a list was added in Django 1.8 - compare https://docs.djangoproject.com/en/1.7/ref/migration-operations/#runsql https://docs.djangoproject.com/en/1.8/ref/migration-operations/#runsql We don't need a list as we run only 1 SQL command. So convert to strings. This helps unbreak Django 1.7. Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephenfinucane@hotmail.com>
* models: Use non-null slugs for 'Check.name'Stephen Finucane2016-06-28
| | | | | | | | | | The schema for 'Check' defines 'Check.name' as a 'CharField'. This is less than ideal as names with spaces and special characters can't be represented cleanly in URLs etc. We should use 'SlugField' instead. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Reviewed-by: Andy Doan <andy.doan@linaro.org> Closes: #33
* models: Add Cover Letter supportStephen Finucane2016-04-01
| | | | | | | | | Cover letters contain useful information that should not be discarded. Store them. This is a prerequisite of series support. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* models: Split Patch into two modelsStephen Finucane2016-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a lot of similarities between cover letters and patches: so many, in fact, that it would be helpful to occasionally treat them as the same thing. Achieve this by extracting out the fields that would be shared between a Patch and a hypothetical cover letter into a "sub model". This allows us to do cool stuff like assigning comments to both patches and cover letters or listing both patches and cover letters on the main screen in a natural way. The migrations for this are really the only complicated part. There are three, broken up into schema and data migrations per Django customs, and they works as follows: * Rename the 'Patch' model to 'Submission', then create a subclass called 'Patch' that includes duplicates of the patch-specific fields of Submission (with changed names to prevent conflicts). Rename non-patch specific references to the renamed 'Submission' model as necessary. * Duplicate the contents of the patch-specific fields from 'Submission' to 'Patch' * Remove the patch-specific fields from 'Submission', renaming the 'Patch' model to take their place. Update the patch-specific references to point the new 'Patch' model, rather than 'Submission'. This comes at the cost of an additional JOIN per item on the main screen, but this seems a small price to pay for the additional functionality gained. To minimise this, however, caching will be added. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Signed-off-by: Andy Doan <andy.doan@linaro.org>
* migrations: Optimize 0007 migrationAndy Doan2016-03-25
| | | | | | | | | By handling comment copying/deletion via SQL we can make migration take < 3 minutes rather than > 30 minutes for big instances. The SQL used is vendor specific, but covers the two DBs supported by Patchwork. Signed-off-by: Andy Doan <andy.doan@linaro.org> Reviewed-by: Stephen Finucane <stephen.finucane@intel.com>
* models: Pull common email behavior into mixinStephen Finucane2016-03-16
| | | | | | | | | | | | | | A "Patch" and "Comment" share a common ancestor: emails. As a result of this many fields are similar between the two. Rather than duplicating code, pull the similar code out of the aforementioned classes and into a Mixin. This has the side effect of removing restrictions on Comment.content, but this is probably OK: it's possible that someone could send an empty mail in reply to a patch and we should show that. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Reviewed-by: Andy Doan <andy.doan@linaro.org>
* models: Merge patch and first commentStephen Finucane2016-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | At the moment a patch is split into two model entries: a Patch and a linked Comment. The original rationale for this was that a Patch is really a sub-class of Comment. A comment is a record of the text content of an incoming mail, while a patch is that, plus the patch content too. Hence the separation and a one-to-one relationship when a patch is present. However, this decision was made before Django added support for model inheritance and is no longer necessary. This change flatten the models in preparation for some email subclassing work. This is achieved by copying over the non-duplicated fields from the Comment to the linked Patch, then deleting the Comment. The migrations are broken into two steps: a schema migration and a data migration, per the recommendations of the Django documentation [1]. SQL migration scripts, where necessary, will need to be created manually as there appears to be no way to do this in a way that is RDBMS-independant [2][3]. [1] https://docs.djangoproject.com/en/1.9/topics/migrations/#data-migrations [2] https://stackoverflow.com/q/6856849/ [3] https://stackoverflow.com/q/224732/ Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Reviewed-by: Andy Doan <andy.doan@linaro.org>
* models: Allow to unselect maintainer projects in user profileThomas Monjalon2016-02-05
| | | | | | | | | | | The admin page for user profiles have a field "Maintainer projects" to grant maintainer rights to an user. It is a list of available projects. When a project was selected, it was impossible to revoke. It is now possible to unselect by clicking while holding the "Ctrl" key. Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
* models: Add DelegationRule objectLaurent Pinchart2016-01-19
| | | | | | | | | Delegation rules are used to automatically set the delegate of a patch based on the files touched by the patch. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
generated by cgit v1.2.3 (git 2.25.4) at 2024-06-11 05:16:42 +0000