- 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 adds a new page with instructions for sharing user invites
if a user clicks the link for one of their own invite codes they are
directed to a page with clear instructions for it's use.
if a user clicks another users link they are redirectec to their account
settings witha flash telling them they do not need to register.
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.
GetCollections and GetPublishableCollections now take a hostname
parameter to allow setting the collecion hostname.
All collections used in memory now have their hostname set.
instead of updating it later. This is more correct behavior, prevents an
additional query, and ensures that potential collection-creation when
claiming posts also respects the default (which it didn't before).
Ref T675
This fixes a bug that occurred only when publishing via API and
authenticating via token (rather than cookie).
Previously, the instance's hostname wouldn't be added to the Collection
that got passed around after retrieving the owned post, meaning an
incomplete URL was returned in the API response, and federation failed due
to the missing host.
Previously, you could create a post with a title but no body, e.g. by
publishing via email. This would still show the post on a blog, but
would give a 410 Gone page when trying to access the page.
This issue originally reported on the forum:
https://discuss.write.as/t/removing-post-unpublished-by-author-post/725
This solves the error 500 on the /api/me endpoint.
Replace token search query `=` with `LIKE` to fix sqlite complaining about
no valid tokens. Also checked with MySQL and it still works after the change.
Now admins can choose a title for their About and Privacy pages; now
editable through the instance page editor.
This adds `title` and `content_type` fields to the `appcontent` table,
requiring a migration by running `writefreely --migrate`
The content_type field specifies that items we're currently storing in
this table are all "page"s; queries for fetching these have been updated
to filter for this type. In the future, this field will be used to
indicate when an item is a stylesheet (ref T563) or other supported
type.
Ref T566
This adds a "Pages" section to the admin part of the site, and enables
admins to edit the pre-defined About and Privacy pages there, instead of
on the dashboard itself.
It also restructures how these pages get sent around in the backend and
lays the groundwork for dynamically adding static pages. The backend
changes were made with more customization in mind, such as an
instance-wide custom stylesheet (T563).
Ref T566
Previously when looking up an invite ID that doesn't exist, the database
call wouldn't communicate its non-existence in a standard way --
returning a nil object and nil error. Now the database call returns a
404 error, so handlers can show the correct page.
This includes:
- A new `user_invites` config value that determines who can generate
invite links
- A new page for generating invite links, with new user navigation link
- A new /invite/ path that allows anyone to sign up via unique invite
link, even if registrations are closed
- Tracking who (of registered users) has been invited by whom
It requires an updated database with `writefreely --migrate` in order to
work.
This closes T556
This fixes the --config step so that when setting up a single-user
instance for the first time (and creating the admin user as part of the
process), the database is automatically initialized before creating that
user.
This removes the need for the --init-db command after --config when
setting up single-user instances.
It fixes#59: "no such table: users" error during the --config step on
single-user instances that haven't previously run --init-db.
SQLite doesn't have an `RLIKE` function, so the query for hashtagged
posts was failing before. This adds a `regexp` function to SQLite and
correctly retrieves all posts on a blog with the requested hashtag.
This closes#55
This enables admins on multi-user instances to see all users registered,
and view the details of each, including:
- Username
- Join date
- Total posts
- Last post date
- All blogs
- Public info
- Views
- Total posts
- Last post date
- Fediverse followers count
This is the foundation for future user moderation features.
Ref T553
This adds a new `sqlite` build tag that you should include only if you
want SQLite3 support built in. Both `make run` and `make release` create
builds with SQLite included.
This adds a "Reader" section of the site for admins who want to enable
it for their instance. That means visitors can go to /read and see who
has publicly shared their writing. They can also follow all public posts
via RSS by going to /read/feed/. Writers on an instance with this
`local_timeline` setting enabled can publish to the timeline by going
into their blog settings and choosing the "Public" visibility setting.
The `local_timeline` feature is disabled by default, as is the Public
setting on writer blogs. Enabling it adds a "Reader" navigation item and
enables the reader endpoints. This feature will also consume more
memory, as public posts are cached in memory for 10 minutes.
These changes include code ported over from Read.Write.as, and thus
include some experimental features like filtering public posts by tags
and authors. These features aren't well-tested or complete.
Closes T554
We store times in UTC in all other places, but the post.Created logic
when creating a post meant that dates were being stored in a user's
local timezone. This fixes that.
Ref T529