| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change add patch 'tags', eg 'Acked-by' / 'Reviewed-by', etc., to
patchwork.
Tag parsing is implemented in the patch parser's extract_tags function,
which returns a Counter object of the tags in a comment. These are
stored in the PatchTag (keyed to Tag) objects associated with each
patch.
We need to ensure that the main patch lists do not cause per-patch
queries on the Patch.tags ManyToManyField (this would result in ~500
queries per page), so we introduce a new QuerySet (and Manager) for
Patch, adding a with_tag_counts() method to populate the tag counts in a
single query.
As users may be migrating from previous patchwork versions (ie, with no
tag counts in the database), we add a 'retag' management command.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
| |
The Message model was deprecated in 1.4, and removed in 1.6
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
| |
patchwork_patchchangenotification_id_seq does not exist,
so running this script simply fails with a rollback
Signed-off-by: Simo Sorce <idra@samba.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
|
| |
Add a PatchChangeNotification model to keep track of changes to a
patch's state. Hook this up to Patch's pre_save signal.
Requires a DB schema upgrade.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
We're going to start generating emails on patchwork updates, so firstly
allow people to opt-out of all patchwork communications.
We do this with a 'mail settings' interface, allowing non-registered
users to set preferences on their email address. Logged-in users can do
this through the user profile view.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
|
|
| |
Since we have infrastructure for email confirmations, we no longer need
the separate registration app.
Requires a migration script, which will delete all inactive users,
including those newly added and pending confirmation. Use carefully.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having a UserPerson-specific confirmation, add an
EmailConfirmation object to allow multiple types of confirmations (eg,
opt-out requests in future).
To do this, we use a view (patchwork.views.confirm) that will call the
type-specific view with the confirmation object.
Also, add tests to check that the User/Person linkage system works.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since c105cb0 (Initial bundle reordering support, 2009-01-29), the
patchwork_bundle_patches table and its associated id sequence does not
exist. The script to grant appropriate privileges was not updated when
this change was made, and causes the set-up procedure described in
docs/INSTALL to fail.
This change adjust the script to grant appropriate access rights to
match the change in the DB schema.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
Mysql doesn't support granting to multiple tables, and requires a
different username format.
Would be nice to code the permissions somewhere, then generate the
grant statements as required.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
