This is a bit more standard, and has the bonus of being compatible with Devise, which is using `flash[:notice]` and so its flashes were coming out unstyled, oops!
Hey nice!!
Note that I removed an account delete button from the settings page. You can still send a DELETE request to the right endpoint to do it, but it's not gonna delete all the associated records, and I wanna think a bit about how to handle that better before exposing that button.
I noticed this was stopping changing your default list visibility bc contact neopets connection can't be empty, so I fixed that!
And then I just decided to scroll through every `belongs_to` relationship and add optional to the ones that jumped out at me lol
A lot of rough edges here (e.g. no styles on the flash messages), but it's working and that's good!!
I tested this by temporarily switching to the production database and logging in as matchu!
Still missing a lot of big features too, like registration, password resets, settings page, etc.
This removes login/logout/session logic for integrating with OpenNeo ID, replacing them with stubs that just redirect to `/?TODO` when you click login, and helpers that act as if you're not logged in.
This gives us a clean slate to plug in new Devise logic to integrate with the `openneo_id` database directly!
No user-facing functionality here yet, just configuring the database connection to work with openneo_id records.
This is a first step in integrating Devise stuff into this app instead of connecting with a weird second app.
My basic testing for this was to temporarily connect to production `openneo_id`, and see `AuthUser.first` correctly return a user!
This will enable us to access the auth records, which we store in a separate database for weird legacy reasons!
We don't do anything else yet, just set up the connection to be available.
(NOTE: This commit was a bit of a history rewrite: we started working on this with `database.yml` still gitignored, but then in 8fb6e82 we added it back in to be able to fix a bug in 44c42f9. So previously this branch added back `database.yml` to git *and* added `openneo_id` to it, but since then I've rebased against the other changes, and rewrote history to make this a change to *just* add the database! I also moved it in the timeline, to be before some of the other things that depend on it.)
I had added this many Rails versions ago during the recent upgrade process, because it was in latest Rails but not in the version of Rails I was using when replacing Elasticsearch with MySQL queries. We can remove it now!
Without this, searches for negative of `fits` or `species` would crash, bc somewhere Rails set the default SQL mode to be stricter than before. This just sets it back!
We gitignored it a long time ago as the way to hide our db secrets, but that's not how we manage them anymore! (Or, well, we haven't done production deployment with this new setup yet, but you get the point.)
This helps clarify what the database config oughta look like!
lmao I keep forgetting things! note that the negative case of this filter, like the negative case of `fits`, is currently broken because Rails changed the default SQL mode and I didn't notice! We'll need to add a `database.yml` file and set `sql_mode: TRADITIONAL`.
Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
Hey nice! We have to add webrick now because it's not included in Ruby 3, but hey just drop it right back in.
Idk how to choose between this or puma or whatever, but in the absence of a specific reason let's just pick the one whose name I know best.
This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
The session format changed, so we change the session cookie name rather than have things crash about it! (I hope the actual prod behavior is to ignore bad cookies rather than crash? But I figure this is more reliable anyway.)
I ran `rails zeitwerk:check`, which eager-loads the app, and it found two problems: `closet_group.rb` doesn't define `ClosetGroup` (cuz it's empty), and I left in a reference to a cache sweeper observer oops. Goodbye!
Rails 5 added new validation on `belongs_to` to ensure the corresponding record exists. In the case of moving to the null list, this shouldn't trigger!
I wish we could flag that specifically `nil` is okay, but other values should be validated? But oh well, this is fine!
Ok so weird little situation, usually Arel will accept an attribute as a param to `order()`, but not when it's in a very specific situation of all of the following:
`Item.joins(:translations).includes(:translations).limit(30).order(Item::Translation.arel_table[:name])`
For some reason, it's all like "hey I can't call `to_sql` on an attribute!", but only in the scenario where all 3 of those other things are present. Weird!
Anyway, explicitly saying `.asc` fixes this. Ok!
Some important little upgrades but mostly straightforward!
Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well!
Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
Some tricks required here to get the dependencies to work out, but we got it!!
Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
This labeling technique hasn't worked in a long time bc it requires being logged in. These days we just manually label them with the 2020 support tools I think!
Clearing out the Neopets gem should help us manage some gem dep conflicts in the 4.2 upgrade too (I think the nokogiri one gets tricky?)
Idk I guess these are the default place to put certain settings, but idk if they're still canonical, and I'd rather just not have files that don't mean anything rn!
Idk exactly what's going on with dotenv-deployment, if it turns out it was critical to our deploy process then we'll change the deploy process! It's deprecated and conflicts with gem deps for `dotenv-rails`.
Grouping stuff a bit more sensibly and with explanations! I just finished deleting a bunch of gems we're not really using, and this helped me audit that the ones we still have here we generally actually want.
idk why we were pulling from git before, probably to get a feature that wasn't pushed to rubygems yet? But now the latest rubygems version matches the latest repo commit (both back in 2017 lol), so let's do that for greater stability and clarity!
