-
-
Notifications
You must be signed in to change notification settings - Fork 867
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User can block instances (fixes #2397) #3869
Conversation
Hey there, quick question: should there be an update here to the "Resolve Object" code so it would be possible to figure out the InstanceId by providing the URL of an instance? I'm thinking, for example, if you wanted to allow users to type in instances to block on the front-end, it would need a way to convert it to an InstanceId. Or more selfishly, for my own application :) Also it's the most trivial comment ever, but I'll be that guy: a few of the added items still say things like "Block a community" instead of "Block an instance". EDIT: I suppose you can always figure out all the Instance IDs by calling the |
@CMahaff Thanks I updated the comments. Yes I think it makes most sense to block instances with a dropdown of FederatedInstances, instead of pasting a raw url. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see now why you added post_aggregates::instance_id
.
Mainly just timestamp fixes, now that the TZ stuff is merged.
Oh and also run lint.sh
, which should fix the SQL formatting.
src/api_routes_http.rs
Outdated
@@ -136,6 +137,7 @@ pub fn config(cfg: &mut web::ServiceConfig, rate_limit: &RateLimitCell) { | |||
.wrap(rate_limit.message()) | |||
.route(web::get().to(resolve_object)), | |||
) | |||
.service(web::resource("/block").route(web::get().to(block_instance))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably be under the site
heading, so its site/block
, not a top-level one. Or maybe POST instance/block
Also this should be a web::post()
like the other blocks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to post and moved under site now. It would also make sense to do user/block_instance
instead, but that would be inconsistent with community/user blocks.
0131eab
to
6993205
Compare
Added an api test for this. Needs new lemmy-js-client version to get it passing. |
I'll start a new lemmy-js-client rc shortly. |
K should be deployed in a few minutes, |
Updated, although the new test is failing... |
* Adding block instance. - LemmyNet/lemmy#3869 * v0.19.0-rc.4 * Forgot to add types. * v0.19.0-rc.5 * Fixing optional site issue.
f4a0c85
to
e8e9a29
Compare
One of the new federation tests is broken. |
I know, but not sure whats causing the failure. |
Question about this functionality, will user instance blocking make sure I cannot see anything anymore from that blocked instance? Because this is what I am looking for tbh, I want to be able to completely black-hole an instance. Like defederation an admin of an instance can do but on a personal level |
See here. |
@dessalines @Nutomic is this slated to be part of the 0.19 release? This is a feature a lot of people asked for. |
Found the problem, I was passing the wrong instance ID. Ready to merge now. @SleeplessOne1917 Yes definitely |
@Nutomic I'll have to make a UI change to accommodate that then. This will also require the JS client be updated. |
|
Tests passing locally. |
Analogous to the existing community block functionality, users can also block instances. This means that all content from communities which are hosted there is hidden. Posts from users of blocked instances are still visible in other places.