Most of these were suggested by PyCharm, and include everything from
little syntax issues and other bad smells to dead or bad code.
Signed-off-by: Dan McGee <dan@archlinux.org>
On the download page, the explicit sorted() call was forcing evaluation
of the Django queryset, even if we never actually needed the results
because the template fragment was cached. Wrap it all in a callable
function which looks the same to the template, but saves us the cost of
evaluation every single page view.
Signed-off-by: Dan McGee <dan@archlinux.org>
We now always look for this information at the URL level, not the mirror
level. This simplifies quite a bit of code in and around the mirror
views.
Signed-off-by: Dan McGee <dan@archlinux.org>
Commit 4c69911982 had an inadvertent side effect here; we need to
explicitly disable ordering for the annotate() to work correctly.
Signed-off-by: Dan McGee <dan@archlinux.org>
This should prevent the need for monthly template updates from Pierre
and Thomas; best to just let them enter the data themselves and have it
show up on the website.
Signed-off-by: Dan McGee <dan@archlinux.org>
This seems like a more appropriate place, and now the visualization is
done here anyway so we should move the data backing it.
Signed-off-by: Dan McGee <dan@archlinux.org>
This doesn't prevent unauthenticated users from accessing the feeds, but
it should reduce clutter and confusion on the feeds index page for users
unlikely to need these feeds.
Signed-off-by: Dan McGee <dan@archlinux.org>
* Import signatures for all known keys, not just active developers
* Ensure we are only showing and accounting for active developers on the
master keys page
* Add a new table showing signatures between developers
Signed-off-by: Dan McGee <dan@archlinux.org>
This will prevent [staging] packages from cluttering normal user's view
on the website, but allow us to still import everything from this
repository for developer use.
Signed-off-by: Dan McGee <dan@archlinux.org>
Now that Django actually provides a concise way to use a RequestContext
object without instantiating it, we can use that rather than the old
function-based generic view that worked well to do the same.
Additionally, these function-based generic views will be gone in Django
1.5, so might as well make the move now.
Signed-off-by: Dan McGee <dan@archlinux.org>
* Add a migration to drop the old countries field.
* Update all templates/views/utility methods to point at the new country
field and dereference it as necessary.
* Add the flags images to a few views where it makes sense.
* Cleanup the download page layout quite a bit.
* Bump the mirror status JSON version to 3; add country_code attribute.
Signed-off-by: Dan McGee <dan@archlinux.org>
We're going to move to using ISO 2 character codes via django countries,
so start by moving the old data out of the way first.
Signed-off-by: Dan McGee <dan@archlinux.org>
This shows the cross-product of each master key with each developer key
so you can see who has been signed, where signatures are missing, etc.
Signed-off-by: Dan McGee <dan@archlinux.org>
Now that we aren't using the middleware, add cache headers on our
primary pages so we can prevent some repeat traffic, and cache all feeds
for five minutes.
Signed-off-by: Dan McGee <dan@archlinux.org>
Add a 'latin_name' field to the user profile so we can better support
those developers with names in non-Latin scripts, and yet still show a
Latin name as necessary on the developer profile page. This field only
shows up if populated.
Also, use consistent sorting everywhere- rather than using username,
always use first_name and last_name fields.
Signed-off-by: Dan McGee <dan@archlinux.org>
We had this set up as a unique ForeignKey before, which adds some
indirection due to the RelatedManager object being there. By making it a
OneToOneField, we can get the profile object directly, enforce uniqueness,
and also use it in select_related() calls to make our profiles page a bit
more efficient.
Signed-off-by: Dan McGee <dan@archlinux.org>
South actually makes this relatively painless if you get everything right,
so might as well start getting these out of the legacy main application to
eventually eliminate models being separate from their views.
Signed-off-by: Dan McGee <dan@archlinux.org>
We had a bunch of extra imports, non-conventional variable names, spacing
issues, etc. that were relatively low-hanging fruit to clean up. Fix them
and make the code a bit cleaner in the process.
Signed-off-by: Dan McGee <dan@archlinux.org>
Get this working by doing some class business with CSS in order to highlight
the correct tab. I had to add some stuff to a variety of pages but it should
be working correctly now. Addresses FS#19591.
Signed-off-by: Dan McGee <dan@archlinux.org>
Rather than our home-baked roles field, which is free text so we really
shouldn't be checking against anyway. It also prevents people from being
both a developer and a TU.
Signed-off-by: Dan McGee <dan@archlinux.org>
Instead of doing slicing and ugly table-based layout, move to a CSS-based
organization of the donor list. Shoot for 4 columns but should degrade
gracefully to fewer, and will look just fine with no CSS at all (one big
tall list).
Signed-off-by: Dan McGee <dan@archlinux.org>
Sometimes http was first, other times ftp was first. Add an order by clause
to ensure it is the same for all mirrors.
Signed-off-by: Dan McGee <dan@archlinux.org>
It isn't the most elegant operation in the world, but attempt to only show
one line per package, grouping by architecture if multiple were updated in
the same go. This makes the recent packages view a bit more useful as a
heads up view. Implements FS#17304.
Signed-off-by: Dan McGee <dan@archlinux.org>
Make the feed framework a lot more flexible and give the possibility to have
a feed for each architecture. You can drill down even more than also get a
feed for a particular repo; some might find this helpful for something like
tracking [testing]. Implements FS#12939.
I also bumped up the number of items available in each of these feeds; since
it is full of a bunch of small items it might be more helpful to have more
available and it should also prevent fewer ones from being missed.
The UI isn't exactly spectacular, but I figured some sort of page is better
than none listing all the various feeds you can pull from.
Signed-off-by: Dan McGee <dan@archlinux.org>
Quite a few changes here. Unify the developer view pages into one actual
django view and template, and use different dispatches from urls.py to set
up the three different queries for who to display and what message and group
name to show.
Signed-off-by: Dan McGee <dan@archlinux.org>
