Previously, anyone could access the editor even if they weren't logged
in. They couldn't do much in that case (publishing would fail), but it
could potentially cause some confusion.
Now, users will be sent to the login page, and then redirected back to
the editor once successfully logged in.
- return an error with invalid request types
- simplify json decoding
- return error and success consistent with app conventions
- endpoint change from /api/generate/markdownify to /api/markdown
- fix nil pointer dereference when passing a base_url
- 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.
this adds basic support for importing files as blog posts.
.txt and .md are supported at this time and the
collection is selectable, defaulting to draft.
if a collection is specified the post is federated.
This is the start of all changes needed to support entirely private
instances, where all blogs are only visible to other authenticated users
on an instance (ref T576). It begins by changing how Handler methods check an
endpoint's permissions.
- Renames UserLevelLEVEL consts to UserLevelLEVELType
- Adds UserLevelLEVEL funcs with same names as previous consts. Each
returns a UserLevel
- Adds a new UserLevelReader that restricts access based on app
configuration. This is now used on collections and posts.
- Changes routing a bit so static files are always accessible
- Adds a new interface, Apper, that enables loading and persisting
instance-level data in new ways
- Converts some initialization funcs to methods
- Exports funcs and methods needed for intialization
- In general, moves a ton of stuff around
Overall, this should maintain all existing functionality, but with the
ability to now better manage a WF instance.
Ref T613
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
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 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 "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
This allows admin to edit these pages from the web, using Markdown. It
also dynamically loads information on those pages now, and makes loading
`pages` templates a little easier to find in the code / more explicit.
It requires this new schema change:
CREATE TABLE IF NOT EXISTS `appcontent` (
`id` varchar(36) NOT NULL,
`content` mediumtext CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`updated` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
This closes T533
This is mostly unnecessary, and ensures users don't get confused when
their site doesn't show up because the server isn't seeing a
correctly-set Host header.
