• Documentation should be RST files that can be made compatible with ReadTheDocs using Sphinx

Proposed initial structure (subject to change/refinement):

• Installation
  • Automated setup using zipped settings.py
  • Manual settings.py setup instructions
  • Runtime Site Settings
  • Email Setup
  • Paypal Setup
• Basic Usage
  • CMS Setup (Mostly Links to Django CMS Documentation)
  • Registration Process
  • Door Registration Process
  • Vouchers
  • Discount System
  • Emailing Students
  • Substitute Teachers
  • Stats
  • Basic Financial Reporting
• Users/Permissions
• Site customization
  • Template customization
  • Registration form customization

Currently when the website is locally run and the user has a weak/non-existant connection to the website the payment processor does not show up.

Some kind of error state should ideally be displayed in the case that a customer is in an area with inconsistent connection such as a subway and will know to try registering later.

We have decided that this is something that we want for Boston Lindy Hop, so that all our instructors and people who run registration have an easier way to check for any individuals who are banned from our classes for Code of Conduct issues. This will be a separate app, though it will be installed by default. Here are the main planned features:

• A table with one record per person in which one can add first and last names as well as one or more email addresses, an optional photograph, and a basic notes field that can be used for internal purposes
• If the app is enabled, when a person with the first and last name of a record (or with one of the email addresses listed in one of the records) tries to register, they are prevented from continuing and they see a generic error message indicating that there is an issue with their registration and to contact the school at an email address.
• A second table that logs instances in which the ban flag is triggered and the IP address from which the flag was triggered.
• An option to automatically send an email to an email address whenever a flagged name/email is registered.

The prerequisites app already has features to prevent students from continuing registration if they don't meet class requirements, so this should be a pretty simple thing to implement I think by copying some of the logic from there.

Most admin fields are fine as is, but a few of them have headings that aren't so great. Adding a short_description to all properties that show up in the admin, as well as adding verbose_name properties to all model fields, should fix these issues.

In the template core/base/base_event_registration.html, each type of registration item (special/open/closed series and open/closed events) are rendered in a separate block, but all of the logic of displaying those events is contained within the one template. To simplify the process of changing how registration looks for different types of events (and to make the template more readable and easier to customize), I would like to split each of the five basic types of listing into its own template, which will then just be included in the base template. So, for example, the base template for series with open registration will now just read something like:

{# List of Class Series with Open Registration #}

{% block reg_open_series %}
	{% include 'core/registration/reg_open_series.html' %}
{% endblock %}

Since flagged individual event categories (such as practice sessions) will soon be able to have their events show up totally separately from other types of events (per the issue described in the comments in #31 ), it may be desirable to have them displayed using a custom template as well. So, if a category is flagged to be displayed separately, then the ClassRegistrationView will look for a custom provided template entitled something like 'core/registration/reg_eventcategory_'.html. If that template exists, then it will be included on the registration page to display events in the category. If that template does not exist, then the category's events will still be displayed separately, but a generic display template will be loaded for the category instead. This should permit maximum flexibility in displaying things like weekly practice sessions or other types of recurring events, without having to duplicate or maintain the code behind the rest of the registration process.

As part of this, I will be reorganizing the templates in the core app somewhat. If you're currently modifying any of these default templates, be advised that you may need to move your files once I push this change. Trying to get these types of things done sooner than later to avoid breaking peoples' installations.

This ends up being an issue if you use django-pipeline or whitenoise

The motivation behind this proposal is to make it easier to integrate other payment processors than Paypal, as well as to make it easier to develop testing of the registration system.

These two apps seem to be candidate apps:

• Django-merchant
• Django-payments

Global settings are handled by the Django-dynamic-preferences app, and by default preferences and preference sections are only ordered as they are discovered by the preferences registry. In our case, because preferences come from multiple apps, it's hard to keep things well-ordered.

I've put in a ticket with that project's repo to provide configurable ordering of preferences. In the meantime, I wouldn't mind brainstorming other ways to make the preference pages a little bit more logical.

Right now the only option for how staff expenses are generated is hourly, at the default rate for the category of staffing (instruction, assistant instruction, etc.) However, there are many cases in which this might be inadequate:

• Different hourly rates for different instructors
• Different hourly rates for the same staff member when they are doing different categories of work
• Administrative work is paid daily/weekly/monthly even while instruction is paid hourly

I've almost completed the code for flat rate pricing for venues, and most of the code involved in this feature is just a reapplication of the logic involved in this. So, I'm just going to go ahead and implement this while I still the logic of how flat rate pricing code for venues works is still fresh in my memory.

The key feature here will be that there needs to be the possibility of more than one "StaffMemberPricingInfo" instance per staff member (whereas right now for locations there can be only one pricing rule per location/room), but only one StaffMemberPricingInfo instance per StaffMember and EventStaffCategory. So, for example, I can have a staff member who is paid weekly for their instructional work, but who also gets paid hourly for some additional categories of work that they do.

If no person-specific pricing rules exist, then expenses will still be generated at the default rate for that category. That way, for schools that pay all their instructors at an identical hourly rate, nothing needs to change.

Appears not to be working on a relatively clean install. Spits back to the same page without displaying any form errors, which leads me to believe that there's a validation issue on a non-displayed field.

Right now, if you go to any Django admin page directly (e.g. /admin/), you lose the Django CMS toolbar. This can be confusing, because many editing functions such as adding Series or Related Items are actually done directly in the Django admin.

In principle, Django CMS provides overlay functionality that makes this change unnecessary (see http://docs.django-cms.org/en/release-3.4.x/how_to/toolbar.html). However, in the experience of Boston Lindy Hop we found this to be buggy, and so we changed all of the sideframe/overlay links to be direct links to admin pages.

Getting the toolbar on the admin pages should just involve adding the appropriate template tag to an overridden version of the admin base template. However, there is the potential issue for repeated loading of toolbars if an admin page is loaded via an overlay or sideframe. Since overlays and sideframes are just iframes, getting the Django CMS toolbar on admin pages should be achievable by just overriding the admin base template and adding a piece of Javascript that loads the toolbar only if the page is not in an iframe.

Also, this change will require the overridden base admin to be loaded before templates from django.contrib.admin, and so we will need an app, similar to the djangocms_admin_style app, which is listed in INSTALLED_APPS before django.contrib.admin.

This will also involve going through the existing settings.py from the zip file on my server and getting rid of any extraneous/vestigial settings, of which there may be a couple (IS_LOCAL_WEBSERVER is one, as is REG_VALIDATION_STR).

The instructions should also include a list of settings that can be optionally overridden but don't need to appear in settings.py if you want to accept the default. These include REG_VALIDATION_STR, EMAIL_VALIDATION_STR, and they could probably include others.

In particular, I see the following as potential roadblocks for a novice user to get their site running well. All of these things can be setup in the admin/runtime preferences pages, but either a command line script or an initial setup page would make it much simpler for users to get the basics in place:

• Permissions/User groups (at BLH, we have a Board group, an Instructor group, and a Registration Desk group, each with different permissions, which could be set by default)
• Localization Settings (currency code/symbol)
• Turning on/off high-level basic features (e.g. discounts and vouchers)
• Creating initial Location/DanceType/DanceTypeLevel/DanceRoles/PricingTier
• Setting up a couple of commonly desired pages that can later be edited:
  • A home page
  • A list of instructors page
  • A list of locations page
  • An FAQ page
  • A news page
  • A link in the main CMS menu to the Registration system

It seems like the easiest way to do this will be to create a command-line script that is included in the repo that prompts the user for each of these things.

The Huey package, which handles asynchronous tasks like emails as well as auto-generation of expenses and revenues, is designed to use the Redis backend. In early versions of the package, it was also possible to run Huey using a SQLite storage backend instead. This feature was removed, and so the default configuration of this project requires redis to be installed and the redis-server daemon to be running.

As of version 1.4, it appears that the Huey package has added the choice of a SQLite storage backend in again. Although using Redis is clearly superior for production environments, the lack of configuration required to use Huey for SQLite seems like it will be better for new users to get up and running.

This should just involve changing a couple of lines of code in default_settings.py, and also updating the documentation to explain how to switch Huey to use Redis for production.

See here for more details.
http://huey.readthedocs.io/en/latest/contrib.html

At BLH, we have used the "special" flag to indicate things like visiting instructors that we want to be listed first (and separately) on the registration page. The flag has no other built-in functionality.

However, since non-series public events are getting the ability to be listed separately on the registration page, with easily configurable templates (see #33 ), it seems like Series should have the same capability. This will make it much easier to have flexibility in highlighting workshops or other special types of series. It will also readily provide all of the functionality currently being provided by the "special" flag, so that flag can be dropped.

Now that there's an action/view to repeat events, it's easy to create and list events far into the future, but we may not want all those events to show up on the registration page if they do not start for a long time.

Default should be no restriction, but a configurable option will just limit the queryset that's passed to the template, if any limit is specified.

As of now, I believe that all strings in .py files are initially translatable, but the following still need to be done at a minimum:

• Default templates need to have strings wrapped in {% trans %} or {% blocktrans %} to make them translatable without overriding templates
• The verbose_name property should be specified explicitly for all model fields, so that they can be translated.

See the Django translation docs for more details on best practices for this.

Right now, if one uses the default installation process provided by setup/default_setup.zip (or if one uses the manual installation instructions in the docs, one's INSTALLED_APPS are listed such that all danceschool project apps are included at the bottom. This works because we do not currently override any of the templates provided by django.contrib.admin or any other app. The default setup provides one template (account/base.html) which overrides a template provided by django-allauth, but this template override is not needed in order to have full functionality (it just makes login/logout look pretty).

However, for issue #30 , it would be extremely helpful to have INSTALLED_APPS ordered such that danceschool.core is listed above django.contrib.admin. Then, we could just override the admin templates that are needed to get the CMS toolbar working on admin pages.

This is probably a very simple change to setup/default_setup.py and the installation docs, but I will need to check the docs for the dependencies that we list in INSTALLED_APPS to ensure that there are no conflicts that will arise from the reordering.

Once this is implemented, existing installations will need to reorder their INSTALLED_APPS in order to get expected behavior.

This is in progress and will be added shortly as a new branch that can be worked on.

Because locations' capacity and room information is currently loaded via data attributes on the tags, and not via Ajax, when you edit a Location's information inline, the room and default capacity information doesn't update until the page is refreshed, which is confusing.

These can just be loaded into the EmailTemplate model on startup from an initial template file that is part of the repo.

We have weekly open practices, so it would be nice to "set it and forget it"

Also, our series are always at the same day and time, so making it easier to input that.

like a 'repeat for weeks' option.

At present, the various project apps use the ready() methods of their apps.py to create default data. Examples:

• In the core app, default EmailTemplates for Registrations and Invoices are created
• In the Vouchers app, categories and templates for gift certificates are created
• In the financial app, default Expense and Revenue categories are created

The ids of the created instances are stored in the Django dynamic preferences app, so that the default categories and templates can be referenced easily. Right now, these default model instances are created via get_or_create() methods in the ready() methods of each app. However, this approach does not work for testing purposes, and it is advised against in the Django docs, because the ready() method actually runs against the production data in this case. So, this approach needs to be modified.

See: https://docs.djangoproject.com/en/1.11/ref/applications/

An alternative approach should be to set default values directly in the dynamic_preferences_registry.py of each app. However, this is not presently feasible, because the default value for ModelChoiceFields in django-dynamic-preferences must be None. Either that app will be updated, or this project will be updated so that category and template preferences are set the first time that they are used, rather than the first time that the project is run.

Sent from my Motorola XT1254 using FastHub

Since roles are supposed to be configurable, these hard codes will not behave as expected for a school that does not define "Lead" and "Follow." I believe that the hard-coded references exist in the financial summary tables, as well as in one or two of the school stats graphs.

Also, in core apps.py it is ensured that Lead and Follow roles are created by default, but this should be removed once the hard-codes are removed, since the new "setupschool" command-line command takes care of this for schools that want it.

Early bird discounts are not easily possible using the current discounts or pricing systems. This seems like a desirable thing to have, so we should figure out the best way to make it work more intelligently.

There are, I think, three possible ways for this to be accomplished:

1. Adapt the exisiting flexible "at-the-door" pricing functionality that is currently built into the core app.

By default, the "at-the-door" price is only applied if the user actually registers at the door, i.e. a staff user processes their registration and checks the "This is a door/invoice registration" box in the first step of the process. But, what could probably be implemented relatively easily would be a configurable setting that automatically applies the door registration price to any registration that happens within x days of the start time of a series. The default behavior could remain the same, but this would make it easy to implement any kind of two-tier time-based pricing. The biggest downside to this approach, I think, would be that it's not really suitable for time-based pricing beyond two tiers, and it means that there isn't an option to have early bird discounts and also price door registrations differently.

2. Modify the existing points-based discounts app to also handle time-based discounts.

The discounts app is really built to handle things like multi-class discounts and it doesn't have any time-related features built into it right now. We could try to build something in that requires that all classes that are used to apply a discount must start at least x days in the future. The potential downside to this approach is that the discount system currently automatically selects the lowest-priced discount available for a registration, and so it only allows one discount to be applied. If, for example, one wants to offer $5 off for early birds in addition to other discounts like a multi-class discount, then this is not currently allowed. Enabling cumulative discounts might be implementable though, with some restrictions to prevent problematic cases.

3. Build a totally separate time-based discounts app, that hooks into the registration system the same way that the existing points-based discounts app does.

A separate app could just hook into the registration system using the same signal handlers that the discounts app uses. This could probably be the most flexible option, because it could be built to have multiple time-based tiers. Keeping it separate also avoids some of the potential issues related to cumulative discounts if you opt to offer both time-based discounts and multi-class discounts. The downside is that it involves building another app, and it might be more confusing to have multiple discounts apps than one single discounts app.

Suggestions and brainstorming on how to address this is welcomed!

A confirmation step page would help to ensure that erroneous emails are not send, and that emails are sent to the correct set of recipients.

It's nice to have PaymentMethod be editable on the admin changelist, for when one wants to mark many expenses as paid at once. However, right now it's showing up as a textbox, even though we have nice autocomplete behavior in the actual admin change form and on the Expense submission view.

This may just be an issue with some Javascript not being included in the changelist view.

The following initial tests should be easy to set up. Additional testing of the complete registration process should be easier once we have a more flexible payment processing system in place.

Once this is in progress, these can be separated into separate tickets.

• Core app
  • Create a class Series and observe that it shows up on Registration page
  • Change the class Series' occurrences and ensure that it closes for registration automatically
  • Submit a substitute teacher
• Discounts app
  • Create a discount code that is automatically applied and ensure that it is applied to an attempted registration
  • Create two discount codes that apply to the same registration and ensure that the lower-priced one is applied
• Vouchers app
  • Create a generic voucher code and test that it can be applied to a registration
  • Test the following special voucher restrictions
    • For first-time customers only
    • For prior customers only
    • Customer-specific voucher
    • Expired voucher does not work
    • Limited amount per use
• Financial app
  • Submit an expense and be sure that it shows up
  • Submit revenue and be sure that it shows up
  • Check that an expense item is created for a submitted substitute teacher, for a location, and for a Series teacher
• Private events app
  • Create an event and ensure that a reminder will be sent for that event if requested.

Auto-generation rules will make it easier to ensure that finances are kept up to date with miscellaneous periodic expenses that often tend to be forgotten about in my experience, because they tend to be auto-debited (e.g. website hosting, insurance, etc.) The logic and choices will be the same as they are for flat rate generation of venue and instruction expenses (monthly, weekly, daily), but there will be an option to create the expense item regardless of whether anything is scheduled during that period. There will also be optional start date and end date fields, and a field for how far in advance an expense item should be generated.

This is a lower-priority improvement, (i.e. it might not make it into version 0.2.0), but I'm listing it now because I want to make sure that the changes that will be needed for this are easy to add. I think the main thing is that the RentalInfo class (currently an abstract base class) just needs to be made into a non-abstract class, and we need to create a foreign key relationship between ExpenseItem and the renamed version of that class. That way it's easy to check to see whether a particular rule has been applied in a particular period, and not just (as it stands now) whether a particular person or location has been paid in that period.

I'll also have to do some thinking about how to handle the admin for this.

I recently added fields to the Requirements/Prerequisites admin that show a list of the Customers who excplicitly meet or do not meet certain requirements. This is helpful for audition-only levels (you don't have to search for the customer in the Customer admin to see if they are on the list. However, for non-audition requirements, it would be much nicer if there were a way to do an Ajax lookup of customers to find out whether they meet the requirements for a prerequisite, and then if they do not, give the option to add them to the "override" list of customers who explicitly meet the requirement. For dealing with large numbers of customers and requirements, this would be much more efficient than using the admin.

I don't know how to do this yet (I know that there needs to be an Ajax view, but I'm not sure how to add the autocomplete to the admin in this way), but I'd also be happy to hand this issue off.

Right now, when a customer goes to the registration page, they see a count of current registrants and the option to register themselves based on the number of completed registrations in the system. Once they select 1 or more class series and click the register now button, their choice is entered into temporary session data and they proceed to step 2, where they fill out their name and email, etc. That info is also loaded into temporary session data and they proceed to step 3. In Step 3, the session data is read and used to create a "Temporary Registration" object, applying any discounts or vouchers that they have entered in the process. They are displayed a page with a final summary and typically a payment link. When they click the payment link, the callback to our website creates an "Invoice" object indicating intent to finish registration, and when they finish paying with Paypal, the Invoice is marked as paid, which triggers the Temporary Registration object to be used to create a Final Registration object, and the user is redirected to the success page. Registration session data expires after 15 minutes of inactivity, so if a customer takes too long they are just redirected to start over.

So, right now, , it is still theoretically possible to have a class over-registered by one or two people if multiple people try to register for the last spot simultaneously. For most small series classes this is not a big issue in the experience of BLH. But, the registration system should be general enough to cover registration for larger events where this might be an issue, especially for something like registration-count based pricing tiers where it's important to keep a running count that includes people who have started but not completed the registration process. Per issue #2 , I'd also like to implement private lesson scheduling, in which each item that can be registered for can only be selected by one person, in which case real-time monitoring of in-progress registrations is potentially important.

Upon some reflection, I think that the best solution for this is going to be to create a separate table with three fields:

• a key for matching the row up to a particular customer's registration session data
• The id of the class series or private lesson slot for which they are in the process of registering
• an expiration time

In Step 1, when a customer goes to sign up for a class series, the site looks for how many people have registered plus how many unexpired rows are in the cache table from people who are still in the process of registering for that class, and permits or disallows registration from beginning based on that. As the customer proceeds through the steps of the registration process, the site should also updates the expiration time. For private lessons, since there's only one slot available, that also effectively prevents duplicate booking entirely.

Since many users of this project won't care much about this functionality, I'm inclined to keep it simple while providing the option for enhanced performance. But, we also need to be able to query this as a table, not just as a set of individual cache keys (which from my research, seems like it rules out most standard cache store options). So, for now, this should probably be a standard database table that is queried using the regular ORM and a management command to clean out stale entries, similar to the way that Django's default database-backed session store works. If someone needs this to be higher-performance than is feasible with a disk-based database, they should be able to configure their installation to improve performance considerably by routing this particular table to be handled by something like an in-memory SQLite or MySQL database.

My knowledge on these issues is limited, so I welcome comments from anyone who has experience with these kinds of performance questions. @afs2015 @Kirkalicious @NorthIsUp .

Right now the project only support USE_TZ = False, but it should be agnostic to the USE_TZ setting.

Steps that need to be taken:

• Converting all uses of datetime.datetime.now() to django.utils.timezone.now(), which behaves appropriately regardless of which way USE_TZ is set.
• Ensuring that date comparisons are done only using local times.

See for more information:

https://docs.djangoproject.com/en/1.11/topics/i18n/timezones/#time-zones-faq

Maybe there's a stylesheet that needs to be included in the overridden admin template?

Point-of-sale integration is something that I would like to get implemented somewhat soon, since I think that it may be important for many schools. Square is probably the best known small-scale point of sale provider, and since they also now accept online payments with their v2 API. So, they seem like a good fit to be implemented as a payment processor with a point-of-sale option.

See for more details: Square docs

Prior to this, I started to implement Paypal Here integration (see the "paypal_here" branch of the repo), but their current API appears to have limitations that lead me to believe that it may not be worth finishing for the time being (specifically, I don't think that Paypal Here transactions can be looked up after the fact using the REST API). If their API improves, then this could be finished up later on.

Ideally, this would be done soon. However, other obligations are likely to prevent me from working on it for some time. If anyone wants to take this project on, I am more than happy to hand it off, and to provide guidance in what's needed to make it work.

The current functions in the vouchers app aren't hooked into from anywhere, and they are built under the assumptions of the old Paypal IPN system. Get them working again.

Related items are supposed to show up at the bottom, but they don't. It's probably a simple fix.

Right now, admin form submission pages lead to an immediate redirect with no success message, which is confusing. I think we can use the Django messages system to easily create a nice confirmation page that ends with a redirect to the specified success page.

Some schools that have their own well-functioning websites may not want to switch to Django CMS right away, but they may still want to switch to this registration system right away. To make this easier, there should be an option in the setupschool script to configure urls for a "registration-only" implementation in which the registration page is the front page of the site. That way, a school could simply add a link to, say, registration.mydanceschool.com, which holds their Django installation with their registration system.

There are probably a couple of different ways to do this, but I suspect that the easiest will be to use a pretty straightforward implementation of Django CMS apphooks. I will look into it to see what is the best way to proceed.

The line item for the discount should only show up if the student price is lower than the non-student price would have been.

This ensures that any price discrepancy between the prices listed on page 2 and page 3 of the registration process is explained to the customer (since we can't apply a student discount until they check the box indicating that they are a student).

Check the conditions for how accrualDate is set when this form is submitted, and ensure that all cases are covered.

We may need to add license files to the repo for these specific things. They live in the static/js and static/css subfolders of each individual app in the project.

The easy_install script can populate the stats page with the standard set of stats charts, but this change will allow the charts to be included elsewhere, and it will allow users to add/remove stats charts that are most useful to them.

It's possible to change the instructor image thumbnail size already by overriding the template, so is it sufficiently more convenient to allow image size or thumbnail parameters to be specified? If so, then implement it.

currently per hour pricing is available, we have venues that are priced as "$400 for the evening" regardless of the exact hours.