chicagoworldcon / wellington Goto Github PK

In a given year, a convention could have anywhere from zero to three Retro Hugos. However, the mailers, etc., that talk about the Retro Hugos aren't really written in a way that will accommodate that possibility.

In an ideal world, the site would be able to calculate on its own how many Retro Hugos were happening and for what year, and compose mailers, membership descriptions, and the like accordingly. (This would, however, need to be human-overridable.)

We have one flaky spec that fails sometimes in automation. I really want it gone.

I'll capture the actual result next time; I pushed the "make it retry" button too fast today, under unrelated time pressure.

Users who log in to purchase a membership might miss that they have one, since this flow never shows existing memberships:

• click 'Purchase Membership'
• select new membership option
• enter email
• click the login link
• land on the new membership form

At no point in this do we show them any sense that they already have one. We should.

One idea would be to have the login link redirect to "My Memberships" every time. Other ideas are welcome.

The First Worldcon, teen, YA, and Child memberships should not show as upgradeable.

We currently have (very useful) global variables for the opening of nominations ($nomination_opens_at), the opening of Hugo voting ($voting_opens_at) and for the end of Hugo voting ($hugo_closed_at). We do not, however, have one for the end of nominations. Instead, we tend to use hard-coding, which isn't good at all. We need to add a global variable to the hugo.rb initializer for close of nominations, and then update views, mailers, helpers, .env, and the like accordingly.

The issue is that in lib/tasks/dev.rake, we have the following code block:

  namespace :reset do
    desc "Sets db/structure.sql to the same as master"
    task :structure do
      system("git checkout --force origin/main db/structure.sql")
      system("git reset db/structure.sql")
    end
  end

(The key bit to notice is --force origin/main.)

At this point, wellington/main and wellington/staging have diverged enough that this makes subsequent database creation impossible.

This is a configuration change on the environment.

This change goes into wellington.env:

# Instalment amounts for users to choose from
# If not specified, defaults to $75 and $50
INSTALMENT_MIN_PAYMENT_CENTS=3000
INSTALMENT_PAYMENT_STEP_CENTS=3000

Things like country name, state, etc, should be canonicalized -- stripped of whitespace, standardized case

It points to .php instead of to the bare URL

There's a way to handle html in I18n that hasn't thus far been honored. We need to fix any broken and/or unsafe HTMLthat may exist in any of the I18n yml files.

This may take the form of just allowing us to do negative credits to the source membership to reset them to "supporting" while crediting a positive payment to the new member.

Send a single email in case of cheque / instalment -- refer to the template Alexia is sending me.

Creating an actual story for this. Because we carried this over from Gitlab, but somehow we didn't copy the story.

Previous branches, for reference, include:
Chris's original WIP branch
and
A bashing branch for the branch above.

Supporting members can upgrade to attending on an installment plan, which sets their upgrade price to the current attending rate instead of some future price.

We don't need to support that mechanism directly, but we need the checkbox on the supporting membership page, so that registration knows who to contact to follow up.

Offers right now are upgradeable based on price, and the specs reflect that. That blocks fixing #73

This image shows a defect in that the First Worldcon membership does confer voting rights, but because voting isn't enabled yet, it's not showing up here.

Titles for memberships use rails' humanize and it looks like shit

I want the name to be more computer-oriented, for querying, and display_name to be settable for humans. I'm fine with the display_name defaulting to name.humanize but let's make it easier to look good.

nomination_mailer.rb and rank_mailer.rb generate mailings using con-specific methods. We need to create relevant methods for Chicago. Since there have been some database changes since these were last used (the implementation of the con-specific contacts, for instance) this is going to require more than just slapping on a coat of paint.

Unsurprisingly, a lot of the mailer previews that derive from nomination_mailer.rb and `rank_mailer.rb are currently broken. Making sure that those work properly is a part of this tory.

There are a few conflicts when merging, due to moving data out into con data bundles. We need to resolve those and merge.

Rather than WORLDCON_CITY=chicago we should have WORLDCON_NUMBER=worldcon80 -- keep the full word in there, just so it's easier to make sense of.

If you're feeling super energetic, change the name in the env var of the ChicagoWorldcon/infrastructure project's config. :D

See here:

That should be a link to the charges route:

      # FIXME: This actually doesn't render as HTML in the view and I have no idea why
      flash[:notice] = %{
        You've just reserved a #{@my_offer.membership} membership. Go to <a href="#{view_context.charges_path}">the Charges page to pay</a>
      }.html_safe

That doesn't work, though.

The Cart has a couple of formatting issues that need to be addressed:

(1) The Cart icon itself is the source of most of the issues, specifically:
(a) It is weirdly huge and incongruous;
(b) It ought to be in the menu bar next to the hamburger icon, and styled consistent with the hamburger icon;
(c) It is split in half on Safari.

(2) The other issue is that, on the reservation page, the payment button group sometimes doesn't respond well to sizing. This seems to be because, for whatever reason, the buttons have some unnecessary nesting going on-- columns within a button-group that contain input objects that are themselves buttons. When the nesting is cleaned up, the responsiveness becomes as expected.

When hovering over the links in the membership card, the blue on white turns white on white

(Done criteria copied from BaseCamp:)

Two features required here:

1. When signed in as a user, this works for any membership under that user.

2. When signed in as an operator, this works for any membership. For Support, more specifically, we need to be able to do a lookup by badge number to get a list of all associated memberships.

The installment plan text updates should go out in the "welcome" email for supporting members if they check the installment plan box.

https://docs.google.com/document/d/16Nm5R4uPoldYolsBO2CaC7ny0D4xAVL9 for the text

When looking at an existing contact, many fields saved to the DB are not showing up on the form.

In this image, the DOB is incorrect, and the email was provided

The layouts and views in this project contain an awful lot of in-line styling. This makes the project hard to work on, and (in cases where the in-line styles specify a color) they put us out of conformity with the style guide.

This is a relatively big job, and (as of this writing) not particularly urgent, but doing this would make the project as a whole a great deal easier to work on, and it would make the lives of devs for subsequent cons a bit more pleasant.

Please note: A little of the in-line styling is currently coming in from app/helpers/reservations_helper.rb, and that may not be the only oddball styling source. Whoever does this probably ought to search the project for terms like bg-, border-, text-, and the like, in case there's more of that sort of thing.

When a user is paying for their reservations, they should have the option to say "I'm paying for these by check" and then get instructions on how/where to mail a check.

Like a primitive.

:D

I expect we'll attach this to the cart workflow as a payment button there, and have to make an extra mailer with instructions, and include a notification to the treasurer as well when one selects that.

The font should be metropolis

Colours should be:

$white = #ffffff;
$black = #000000;
$light_blue = #41B6E6;
$red = #DA291C;
$dark_blue = #00558C;

It would be useful to add a note to the member notes list when they change, so that if a member is changed we can see what was done and by whom

In order for the Cart Icon to be visible in the nav bar, the app needs to know that something has been added to the cart. This, alas, does not happen on the index page.

We need to create a view helper to address that, and then call said helper via a :before action in the Application Controller.

In Chicon, the email associated with the User and the email associated with the Contact do not have to match, but the operators need a reasonable way to both disambiguate this and to change them.

A con running Wellington might choose to have their member list visible only to logged in users. Create two things:

1. A membership page
2. The option to have that membership page require a logged in user to see it.

As a user, when I buy a membership I would like to add on a fan fund contribution when paying for a membership.

As the treasurer I want to be able to see the fan fund contributions separately from the registration payments

• Things to consider: Looking at invoices to stripe with product types

Logos, the favicon, and (quite possibly) a few other assets need to be integrated into the site.

Look at member 850 -- some mails seem not to be sending.

Several aspects of the README are centered on the gitlab location. We should clean those up so they reference this location.

• pipeline badges -> actions
• docker image locations
• checkout locations
• contribution guidelines

Any attending membership must have a minimum of $50 paid before it can be kept. Right now that's at $30, which is wrong.

I'd rather get the CoC issue sorted sooner than later. I'll look into some good OSS community codes of conduct and bring those in

Right now we have no mechanism for changing the User email address that member users use to log in. We need a way to do that.

A dump of the database payment info.

• Member numbe
• payment amount
• payment time

Weekly would be nice if you can do just what transpired that week after an initial first dump of everything.

This is so that reservations that are disabled can be tombstoned in the system.

Registration currently has a very arduous process to create a new user: a support user creates a blank contact but doesn't buy it, then uses the support login to transfer it to the selected user.

This should be easier.

It's useful to track negatives so that the amount owning on a reservation is kept accurate.

To reduce confusion between our operators and the concept of a supporting member, let's rename the "Support" user type to "Operator"

Language from Basecamp:

Add email field to the contact info. This is an optional field for contact.

In order to be able to comply with state safety regs, we need to have DOB for child/YA members.

Per the discussion in the weekly sync, we're going to remove the inference of upgradeability with respect to pricing/attendance, and add an explicit keyed upgrade path for memberships.

This will impact #72 #73 and #74