On an instance with millions of posts across all users, a single blog with
thousands of posts on it can take a long time to render. This adds an index
to the `posts` table to speed up the basic GetPosts query.
Run: `writefreely db migrate`
Closes#741
This adds a self-serve password reset page. Users can enter their username
and receive an email with a link that will let them create a new password.
If they've never set a password, it will send them a one-time login link
(building on #776) that will then take them to their Account Settings page.
If they don't have an email associated with their account, they'll be
instructed to contact the admin, so they can manually reset the password.
Includes changes to the stylesheet and database, so run:
make ui
writefreely db migrate
Closes T508
This adds beginning email subscription functionality, with only MySQL support,
Mailgun support, and incomplete support for private instances. It includes
database changes, so run:
writefreely db migrate
to use this feature.
Ref T856
This enables users to add a signature to all blog posts, and update it from a single location.
Requires database migration with: writefreely db migrate
Closes T582
This adds any OAuth login buttons to the invite signup page, stores the invite code for the flow duration, and associates the new user with it once successfully registered.
It enables invite-only instances with OAuth-based registration.
Previously, this migration would cause the error: "Cannot add a NOT NULL
column with default value NULL". This fixes that by setting the default
value for new columns to '' (empty string). It updates the query builder
to support this, too.
Combining all operations into a single query was causing problems in
SQLite. This fixes that by breaking them up into separate queries. It
also moves one column length change to only run on MySQL, since SQLite
doesn't need it.
It's not straightforward to remove these constraints in SQLite, so this
just skips it entirely. Since both of these migrations are part of the
same WF release, this should have minimal impact on admins.
- update error messages to be correct
- move suspended message into template and include for other pages
- check suspended status on all relevant pages and show message if
logged in user is suspended.
- fix possible nil pointer error
- remove changes to db schema files
- add version comment to migration
- add UserStatus type with UserActive and UserSuspended
- change database table to use status column instead of suspended
- update toggle suspended handler to be toggle status in prep for
possible future inclusion of further user statuses
This renders all requests for that user's posts, collections and related
ActivityPub endpoints with 404 responses.
While suspended, users may not create or edit posts or collections.
User status is listed in the admin user page
Admin view of user details shows status and now has a button to activate
or suspend a user.
This makes it so we can keep all schema changes in the `migrations`
module, instead of adding them there *and* in the schema files. It
fixes#92 and should prevent these kinds of issues in the future.
Matt Baer
Matt Baer
Timshel
Nick Gerakines
Rob Loranger
Michael Demetriou