| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The version we have doesn't work in django 2.2. And while there might be
newer ones available, we only use it in the admin interface and the
newer django has it's own functionality for delivering the same thing
there.
|
|
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
|
|
There is an issue with concurrent updates in django admin, in that the
entire entry will be overwritten on save, even if some fields have been
edited concurrently, say by a notification arriving or a cronjob or
something like that.
To avoid this issue, take a hash of all the values when generating a
form and store it in a hidden field. When a form is submitted, compare
this hash to the current values in the database, and if anything has
changed raise a validation error.
Makes no attempt to actually resolve the conflict, it only sets a global
error on the form, and the user has to reload and start over, but it
should prevent concurrent modification.
Has worked in testing, but there are probably some cases where this will
incorrectly reject an appropriate update. Let's hope it's not too many.
There are also likely cases where it misses things, but we should be no
worse off than before this patch.
|
|
This goes through most cases and replaces massive dropdowns or
pairs-of-selects with ajax based lookups using django-selectable. Some
pages go from over 500Kb down to about 30Kb, so it should render th
interface much faster.
Note: only forms in /admin/ are handled by this. Most user facing forms
are already taken care of.
|
|
|
|
|
|
This is a limited wiki for conference attendees, intended for things
like ride sharing or restaurant coordination.
The wiki supports simple markdown syntax, and nothing more than that.
Only admins can create pages (through the dashboard). Each page can
be assigned permissions (public, based on regtype, or individual
attendee) to view and/or edit the pages. *Only* confirmed registrations
will ever be able to see anything on the wiki (unlike previous times
when we've used public pages on the main postgresql.org wiki).
If at least one page is visible to the attendee, the section shows
up on the registration dashboard.
Attendees can subscribe to changes to a page, in which case they will
receive an email when the page is edited. Changes are always sent to
the conference contact address (for post-moderation if required).
History is tracked on all pages, and it's possible to view the history
of a page including diff between versions (unless disabled on individual
wiki pages from the admin interface).
To implement the diff functionality, import the diffablemodel code from
the pgcommitfest app that does similar things, and build on top of that.
|
