-
-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Add from account to notifications api #10796
Add from account to notifications api #10796
Conversation
this adds the ability to filter notifications by the account they originated from
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 like the idea, just need some details changed
* use account id instead of user@domain * name the param `account_id` instead of `from_account`
app/models/notification.rb
Outdated
types = TYPE_CLASS_MAP.values - activity_types_from_types(exclude_types + [:follow_request]) | ||
where(activity_type: types) | ||
return where(activity_type: types) if account_id.nil? |
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.
This is a lambda, not a method, so the return
keyword acts differently here. I suggest just an if/else
block. Or you can change the scope to a class-level method:
class << self
def browserable(exclude_types = [], account_id = nil)
types = TYPE_CLASS_MAP.values - activity_types_from_types(exclude_types + [:follow_request])
return where(activity_type: types) if account_id.nil?
where(activity_type: types, from_account_id: account_id)
end
end
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.
done, though I thought return
acted differently in procs not lambdas
This PR is dependent on another PR getting merged: mastodon/mastodon#10796 . If that PR is not accepted, this can also be closed
* Add `from_account` to notifications API this adds the ability to filter notifications by the account they originated from * passing a non-existent user should cause none to be returned * Fix codeclimate warnings * fix more codeclimate warnings * make requested changes: * use account id instead of user@domain * name the param `account_id` instead of `from_account` * Don't use `return` in a lambda
* Add `from_account` to notifications API this adds the ability to filter notifications by the account they originated from * passing a non-existent user should cause none to be returned * Fix codeclimate warnings * fix more codeclimate warnings * make requested changes: * use account id instead of user@domain * name the param `account_id` instead of `from_account` * Don't use `return` in a lambda
This PR is dependent on another PR getting merged: mastodon/mastodon#10796 . If that PR is not accepted, this can also be closed
* Add `from_account` to notifications API this adds the ability to filter notifications by the account they originated from * passing a non-existent user should cause none to be returned * Fix codeclimate warnings * fix more codeclimate warnings * make requested changes: * use account id instead of user@domain * name the param `account_id` instead of `from_account` * Don't use `return` in a lambda
* Add `from_account` to notifications API this adds the ability to filter notifications by the account they originated from * passing a non-existent user should cause none to be returned * Fix codeclimate warnings * fix more codeclimate warnings * make requested changes: * use account id instead of user@domain * name the param `account_id` instead of `from_account` * Don't use `return` in a lambda
This adds the ability to filter notifications by the account they originated from. Currently there is no UI for this, it only adds the ability to the API.