| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Adds a message to look up a user in the database based on their email
address. If the user does not exist, it is created.
|
|
This uses the simplified view for querying posts instead of the post
table directly to display posts.
|
|
|
|
Updates the generated schema with the new users table.
This commit will break the build.
|
|
Relicense the project from the standard GPL3 to the Affero version of
the license, requiring source code disclosure for modifications made
on instances of Converse that are serving users over the network.
|
|
|
|
|
|
|
|
|
|
|
|
Instead of loading the templates at launch time (which requires the
template folder to be present), include the template strings into the
binary.
This also re-enables auto-escaping in Tera.
|
|
Implements a handler that receives the edit form result and updates
the database accordingly if the user identity matches.
|
|
Simple message intended to be used for post editing.
|
|
Displays an edit form for posts that are owned by a user (which is
currently defined as "email addresses match").
|
|
Very simple message that retrieves a post from the DB.
|
|
|
|
No need to go the intermediate step via `Context::new()`
|
|
Adds a generic template that can be used for submitting, responding to
and editing posts.
|
|
A little bit of logical grouping of things has never hurt anyone.
|
|
|
|
|
|
There are several reasons for this, but one important one is that
people expect to be able to share search links.
|
|
... derp.
Well, the CSP prevented script executions already.
|
|
Implements a very simple and currently kinda broken-looking search
result view.
|
|
... until pagination is in place.
|
|
Schedules refreshes of the database view used for search at one-minute
intervals.
|
|
|
|
|
|
Adds support for executing full-text search across a forum instance by
sending the `SearchPosts` message with a search query to the DB actor.
The struct used for results is mapped manually to the expected query
result as the query is embedded via raw SQL.
|
|
|
|
Adds a 'sticky' column to threads and rewrites the thread index to
take sticky markings into account when ordering threads.
Stickies are not yet highlighted in any way in the forum overview.
|
|
This implements the classic thread ordering expected by most forum
users (i.e. the thread with the most recent post is at the top).
|
|
|
|
This is a simplification over the previous approach. The OP of a
thread is just a normal post like any other in this model, which
allows some code simplifications (and future query convenience).
|
|
Adds a `REQUIRE_LOGIN` environment variable which, if set to anything
other than true, will let users post anonymously on the forums.
|
|
|
|
This took me some time to figure out so it's useful to document in the
commit message.
When chaining messages from actors, the result type of a message (i.e.
the actual `<M as Message>::Result`) is sometimes itself a
`Result<T, E>`.
In many cases this leads to a situation where the return type of a
message sending process is something like (simplified):
Future<Item=Result<Foo, ConverseError>, Error=actix::MailboxError>
Due to the implementation of
`From<actix::MailboxError> for ConverseError` it is possible to use
`.from_err()` on these futures to convert the future's `Error` to
`ConverseError`.
The type `Result` apparently implements `IntoFuture`, which means that
due to some trait magic that's been applied somewhere in the futures
API a call to `flatten()` can "lift" the contained error if the error
types match and give us a "simple"
Future<Item=Foo, Error=ConverseError>
From that point on chaining becomes easy.
|
|
|
|
- ensure users are correctly linked to a post actor after replying
- ensure timestamps are clickable to get post IDs
|
|
|
|
|
|
|
|
Implements a new thread rendering pipeline which all posts and the
main thread body are first converted to a `RenderablePost` structure.
During the conversion to this structure, the post body is rendered as
Markdown and the author's email address is converted into the format
required by Gravatar.
|
|
Required for Gravatar.
|
|
|
|
This currently breaks error handling in page render flows. To fix it
properly, the database actor should return failable futures instead of
`Result<T>` wrapped in a future.
|
|
Adds a separate actor that handles page rendering, templating engine
state and other related topics.
|
|
|
|
Technically the last post date should matter more here, but we'll get
there.
|
