| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit eee60a5332ac0745071086477ff4e189b080d3ab.
Discussion: https://postgr.es/m/ff9d7921-f4e3-498a-9dba-ddd28fdb359f%40eisentraut.org
|
|
Clicking the patch header would sort by the patch ID, but that ID would
not actually be visible. Effectively resulting in random ordering for
the user, so let's just show the ID.
|
|
|
|
|
|
|
|
A long list of ancient commitfests isn't super useful. This puts a few
links at the top of the page that cover the most common usages of the
commitfest app.
|
|
This changes both the storage location of the files and the URL. This
aligns it up with how (almost) all our other django apps work, so good
for consistency.
|
|
All users can still enumerate local users, but the functionality to
search the central database is restricted to admins only.
Reported by Benjamin Flesch
|
|
django-selectable is no longer maintained, and will cause issues in
newer versions of django.
selectize is what we use in the pgeu-system codebase today, so copy the
handling over from there.
|
|
|
|
This avoids useless redirects.
|
|
Per request
|
|
|
|
|
|
These clearly had little to do with reality since they would return
duplicate entries if a patch was in more than one cf..
|
|
This is particularly interesting towards the end of a cycle where it can
be used to flag patches that are not intended for the current version
but still needs review.
|
|
By popular (?) request
|
|
Add some longer texts to indicate what's really hiding behind buttons.
|
|
|
|
|
|
We've long gone past what the django ORM can handle and got into
hundreds of queries for large commitfests. And it's not really that hard
to rewrite as SQL, even though we have to dynamically build the WHERE
clauses. So do that.
|
|
Per discussions at the developer meeting, show the number of CFs a patch
has been on, and make it possible to sort on this value.
|
|
|
|
Reported by Peter Geoghegan
|
|
|
|
|
|
The language attribute has been deprecated for quite some time with
the type attribute setting the type of embedded content. The type
attribute has further been defined to text/javascript as the default
value in the spec, so no attribute should be used for Javascript.
Per the standard: https://www.w3.org/TR/html5/scripting-1.html
|
|
|
|
|
|
|
|
|
|
This makes it possible to receive notifications (via email) when a patch
has been updated.
It's possible to subscribe to notifications on a specific patch. It is also
possible to set the user profile up so that one receives notifications for
all patches where one is author, reviewer or committer on.
Notifications are, of course, only sent when other people make modifications
to the entry.
|
|
Per request during Brussels developer meeting
|
|
As requested by Jim Nasby and Alvaro Herrera
|
|
Grouped by each contriubtor, show which patches this person is the
author and reviewer of, to compare how many of each people have.
|
|
Noted by Erik Rijkers
|
|
Account for the Committer column added in 8495806.
|
|
Pointed out by Andres that the original patch only did the CF
listing, and not the actual patch viewing.
|
|
Per request
|
|
feedback"
Returned with Feedback will now actually close the patch and *not* move it to
the next CF. Since it used to do that, all existing Returned with Feedback patches
are changed to Moved to next CF which does the same thing that Returned with
Feedback used to do. And of course, Moved to next CF is a new option available for
each patch from now on.
|
|
This highlights the different statuses better in a long list.
|
|
|
|
This feature makes it possible to "pull in" a message in a thread and highlight
it with an annotation (free text format). This will list the message in a table
along with the annotation and who made it.
Annotations have to be attached to a specific message - for a "generic" one it
makes sense to attach it to the latest message available, as that will put it
at the correct place in time.
|
|
Noted by Stefan - we did this for everything except the patch history, so
let's make it consistent.
|
|
|
|
Quick overview of how many patches are in each status, as exist on
the old app.
|
|
Reported by Stefan
|
|
This needs to redirect to the login page and back, so the user is
actually logged in when attaching. This was only partially ipmlemented
before, it turns out.
|
|
Instead of having inline stylesheets, put them all in a separate CSS
file. This really should've been done from the beginning, but was
clearly forgotten before deployment.
|
|
Each user can add a secondary email (well, more than one) and then pick
one of those when sending email.
Addresses are validated by sending a token to the newly added address,
with a link to click to confirm it. Only a fully confirmed address can
actually be used.
|
