| Age | Commit message (Collapse) | Author |
|---|
|
When a user signs up, removes their signup, or changes the value of
their signup, we can now send an email to notify the conference
organizers thereof.
Fixes #25
|
|
These were added back in 4b62fb65c3eeadc0aafff44c9b1c7585ccbad84d, but
appears to have never really been necessary. Probably leftovers from
some previous attempt, so clean it up.
|
|
2to3 doesn't do this automatically, probably because weird things can
happen if you had both. We know we didn't, so just do a straight
replacement.
|
|
|
|
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!
|
|
This will be required in future Django versions, and currently throws
deprecation warnings.
|
|
This adds the variables:
ORG_NAME
TREASURER_EMAIL
to settings.py, to be adjusted by local_settings.py, and changes the
membership system to use those variables instead of hard-coded values.
This change allows other pgeu-website based systems to make use of the
general templates without having to override every template.
This also adjusts the jinja rendering to also use settings_context()
and adds these variables into the 'safe_attributes' for all of the
current models.
|
|
Without this, jinja templates can't show the selected choice once a
signup has closed (before that it works througuh the form, but once it's
closed we render the results directly).
|
|
This implements the ability to render confreg templates (registration,
cfp, schedules etc etc) using jinja2 instead of django templates. The
important difference is that these templates are rendered in a complete
sandbox, so they cannot reach into other parts of the system by
exploiting connected objects or by including templates they are not
supposed to.
Jinja templates are used whenever the "jinjadir" variable is set on a
conference. When it is, the variables for basetemplate, templatemodule,
templateoverride and templatemediabase are all ignored, as their
functionality is either no longer needed or implemented in a different
way using the templates.
For the time being we support both the old (django based) templates and
the new (jinja based) templates. That means that any changes made to the
confreg templates must be done twice. At some point not too far in the
future we should decide to either desupport old conferences that have
the old style templates, or re-render those as static. (For closed
conferences most pages aren't reachable anyway, but things like
schedule and session descriptions are reachable way past the end of
a conference)
Along with the templates come a new command called "deploystatic.py",
which runs outside the django environment. This command can be used for
deployment of static sites based on the jinja templates, similar to how
some conference sites have done it before. Since the templates run in a
sandbox, this should be much more safe than what's been done before, and
therefor access can be granted to more people. This command is made to
run standalone so conference template developers can run it locally
without having to install full support for django.
|
|
This means we can have "will attend with a plus one" count as 2 already
in the signup, making it a lot easier to handle limitations on signups.
And also to make "No" count as zero...
If nothing is entered in the field for limits, it will work just like before
and just count the number of entries.
|
|
|
|
nulls are meaningless for many2many and missing/conflicting default values.
|
|
This is somewhat like a "doodle", meaning it's something where attendees
can sign up to extra things. Supports both just a simple "yes" signup,
and also a signup where the attendee picks between a fixed set of
choices.
Signups can be made public (=all attendees can use them), or limited based
on either registration type or individual attendee.
Signups can be configured to be "visible" in which case all other
attendees signed up are shown to all the invited attendees, or they
can be "hidden" in which case only conference administrators can see them.
|
|
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.
|
