* Paginate the outbox responses. Fixes#669
* Address Ana's review
* Make outbox_fetch page through instance outboxes
* Fix infinite loop in fetch_outbox
* Fix off by one
* Begin adding support for timeline
* fix some bugs with parser
* fmt
* add error reporting for parser
* add tests for timeline query parser
* add rejection tests for parse
* begin adding support for lists
also run migration before compiling, so schema.rs is up to date
* add sqlite migration
* end adding lists
still miss tests and query integration
* cargo fmt
* try to add some tests
* Add some constraint to db, and fix list test
and refactor other tests to use begin_transaction
* add more tests for lists
* add support for lists in query executor
* add keywords for including/excluding boosts and likes
* cargo fmt
* add function to list lists used by query
will make it easier to warn users when creating timeline with unknown lists
* add lang support
* add timeline creation error message when using unexisting lists
* Update .po files
* WIP: interface for timelines
* don't use diesel for migrations
not sure how it passed the ci on the other branch
* add some tests for timeline
add an int representing the order of timelines (first one will be on
top, second just under...)
use first() instead of limit(1).get().into_iter().nth(0)
remove migrations from build artifacts as they are now compiled in
* cargo fmt
* remove timeline order
* fix tests
* add tests for timeline creation failure
* cargo fmt
* add tests for timelines
* add test for matching direct lists and keywords
* add test for language filtering
* Add a more complex test for Timeline::matches, and fix TQ::matches for TQ::Or
* Make the main crate compile + FMT
* Use the new timeline system
- Replace the old "feed" system with timelines
- Display all timelines someone can access on their home page (either their personal ones, or instance timelines)
- Remove functions that were used to get user/local/federated feed
- Add new posts to timelines
- Create a default timeline called "My feed" for everyone, and "Local feed"/"Federated feed" with timelines
@fdb-hiroshima I don't know if that's how you pictured it? If you imagined it differently I can of course make changes.
I hope I didn't forgot anything…
* Cargo fmt
* Try to fix the migration
* Fix tests
* Fix the test (for real this time ?)
* Fix the tests ? + fmt
* Use Kind::Like and Kind::Reshare when needed
* Forgot to run cargo fmt once again
* revert translations
* fix reviewed stuff
* reduce code duplication by macros
* cargo fmt
* Make a distinction between moderators and admins
And rework the user list in the moderation interface, to be able to run the same action on many users,
and to have a huge list of actions whithout loosing space.
* Make user's role an enum + make it impossible for a moderator to escalate privileges
With the help of diesel-derive-enum (maybe it could be used in other places too?)
Also, moderators are still able to grant or revoke moderation rights to other people, but maybe only admins should be able to do it?
* Cargo fmt
* copy/pasting is bad
* Remove diesel-derive-enum and use an integer instead
It was not compatible with both Postgres and SQlite, because for one it generated a schema
with the "User_role" type, but for the other it was "Text"…
* Reset translations
* Use an enum to avoid magic numbers + fix the tests
* Reset translations
* Fix down.sql
* Theming
- Custom CSS for blogs
- Custom themes for instance
- New dark theme
- UI to choose your instance theme
- Option to disable blog themes if you prefer to only have the instance theme
- UI to choose a blog theme
* import migrations via macro
* panic on database not to the latest migration
* add subcommand to plm
* create migration that run tantivy index creation
* remove diesel_cli from places it was
* use our migration system for tests
* create table __diesel_schema_migrations if needed
* Big refactoring of the Inbox
We now have a type that routes an activity through the registered handlers
until one of them matches.
Each Actor/Activity/Object combination is represented by an implementation of AsObject
These combinations are then registered on the Inbox type, which will try to deserialize
the incoming activity in the requested types.
Advantages:
- nicer syntax: the final API is clearer and more idiomatic
- more generic: only two traits (`AsActor` and `AsObject`) instead of one for each kind of activity
- it is easier to see which activities we handle and which one we don't
* Small fixes
- Avoid panics
- Don't search for AP ID infinitely
- Code style issues
* Fix tests
* Introduce a new trait: FromId
It should be implemented for any AP object.
It allows to look for an object in database using its AP ID, or to dereference it if it was not present in database
Also moves the inbox code to plume-models to test it (and write a basic test for each activity type we handle)
* Use if let instead of match
* Don't require PlumeRocket::intl for tests
* Return early and remove a forgotten dbg!
* Add more tests to try to understand where the issues come from
* Also add a test for comment federation
* Don't check creation_date is the same for blogs
* Make user and blog federation more tolerant to errors/missing fields
* Make clippy happy
* Use the correct Accept header when dereferencing
* Fix follow approval with Mastodon
* Add spaces to characters that should not be in usernames
And validate blog names too
* Smarter dereferencing: only do it once for each actor/object
* Forgot some files
* Cargo fmt
* Delete plume_test
* Delete plume_tests
* Update get_id docs + Remove useless : Sized
* Appease cargo fmt
* Remove dbg! + Use as_ref instead of clone when possible + Use and_then instead of map when possible
* Remove .po~
* send unfollow to local instance
* read cover from update activity
* Make sure "cc" and "to" are never empty
and fix a typo in a constant name
* Cargo fmt
Also adds a parameter to `md_to_html` to only render inline elements (so that we don't have titles or images in blog descriptions). And moves the delete button for the blog on the edition page.
I still have to update the SQLite migration once others PRs with migrations will be merged.
Also, there will be a problem when you edit a blog while not owning its banner or icon: when validating they will be reset to their default values… I don't see a good solution to this until we have a better way to handle uploads with Rocket (the same is probably happening for articles btw).
And the icon/banner are not federated yet, I don't know if I should add it to this PR or if it can come after?
Fixes#453Fixes#454
We add clippy as our build — also rectifying the missing `plume-cli` build!
In the next step we follow clippy's advise and fix some of the "simple" mistakes in our code, such as style or map usage.
Finally, we refactor some hard bits that need extraction of new types, or refactoring of function call-types, especially those that thread thru macros, and, of course functions with ~15 parameters should probably be rethought.
- Use `Result` as much as possible
- Display errors instead of panicking
TODO (maybe in another PR? this one is already quite big):
- Find a way to merge Ructe/ErrorPage types, so that we can have routes returning `Result<X, ErrorPage>` instead of panicking when we have an `Error`
- Display more details about the error, to make it easier to debug
(sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)
Add some support for comment visibility, fix#217
This add a new column to comment, denoting if they are public or not, and a new table linking private comments to those allowed to read them. There is currently no way to write a private comment from Plume.
Git is having a hard time what happened in Comment::from_activity, but most of it is just re-indentation because a new block was needed to please the borrow checker. I've marked with comments where things actually changed.
At this point only mentioned users can see private comments, even when posted as "follower only" or equivalent.
What should we do when someone isn't allowed to see a comment? Hide the whole thread, or just the comment? If hiding just the comment, should we mark there is a comment one can't see, but answers they can, or put other comments like if they answered to the same comment the hidden one do?
* Count items in database as much as possible
* Fix the tests
* Remove two useless queries
* Run pragma directive before each sqlite connection
* Pragma for tests too
* Remove debug messages
All the template are now compiled at compile-time with the `ructe` crate.
I preferred to use it instead of askama because it allows more complex Rust expressions, where askama only supports a small subset of expressions and doesn't allow them everywhere (for instance, `{{ macro!() | filter }}` would result in a parsing error).
The diff is quite huge, but there is normally no changes in functionality.
Fixes#161 and unblocks #110 and #273
* Add search engine to the model
Add a Tantivy based search engine to the model
Implement most required functions for it
* Implement indexing and plm subcommands
Implement indexation on insert, update and delete
Modify func args to get the indexer where required
Add subcommand to initialize, refill and unlock search db
* Move to a new threadpool engine allowing scheduling
* Autocommit search index every half an hour
* Implement front part of search
Add default fields for search
Add new routes and templates for search and result
Implement FromFormValue for Page to reuse it on search result pagination
Add optional query parameters to paginate template's macro
Update to newer rocket_csrf, don't get csrf token on GET forms
* Handle process termination to release lock
Handle process termination
Add tests to search
* Add proper support for advanced search
Add an advanced search form to /search, in template and route
Modify Tantivy schema, add new tokenizer for some properties
Create new String query parser
Create Tantivy query AST from our own
* Split search.rs, add comment and tests
Split search.rs into multiple submodules
Add comments and tests for Query
Make user@domain be treated as one could assume
* Run cargo clippy on plume-common
Run clippy on plume-common and adjuste code accordingly
* Run cargo clippy on plume-model
Run clippy on plume-model and adjuste code accordingly
* Reduce need for allocation in plume-common
* Reduce need for allocation in plume-model
add a quick compilation failure if no database backend is enabled
* Run cargo clippy on plume-cli
* Run cargo clippy on plume
With this patch, Plume will be use a more up-to-date revision of
Rocket, that works with nightly-2018-07-17. It may have been able to
make it work with a more recent revision, but it turns out rocket has
introduced several breaking changes so I’d rather fix those.
Besides updating rocket_i18n and rocket_csrf to use the same revision
than Plume, this patch deals with the new implementation of the
Uri<'_> type. It silents a class of warnings, to deal with a change in
rustc which affects diesel. This latter change should be reverted as
soon as diesel releases a new version of its crate.
The code is divided in three crates:
- plume-common, for the ActivityPub module, and some common utils
- plume-models, for the models and database-related code
- plume, the app itself
This new organization will allow to test it more easily, but also to create other tools that only reuse a little part of
the code (for instance a Wordpress import tool, that would just use the plume-models crate)
