discourse/app/serializers/current_user_serializer.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

319 lines
7.1 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
2013-02-06 03:16:51 +08:00
class CurrentUserSerializer < BasicUserSerializer
2013-02-26 00:42:20 +08:00
attributes :name,
:unread_notifications,
:unread_private_messages,
:unread_high_priority_notifications,
:read_first_notification?,
2013-02-26 00:42:20 +08:00
:admin?,
:notification_channel_position,
:moderator?,
:staff?,
:title,
:any_posts,
:enable_quoting,
:enable_defer,
:external_links_in_new_tab,
:dynamic_favicon,
:trust_level,
:can_send_private_email_messages,
:can_send_private_messages,
:can_edit,
:can_invite_to_forum,
:no_password,
:can_delete_account,
:should_be_redirected_to_top,
:redirected_to_top,
:custom_fields,
2014-06-19 02:04:10 +08:00
:muted_category_ids,
:regular_category_ids,
:tracked_category_ids,
:watched_first_post_category_ids,
:watched_category_ids,
:muted_tag_ids,
:watched_tags,
:watching_first_post_tags,
:tracked_tags,
:muted_tags,
:regular_tags,
:dismissed_banner_key,
:is_anonymous,
:reviewable_count,
:read_faq,
:automatically_unpin_topics,
:mailing_list_mode,
DEV: Topic tracking state improvements (#13218) I merged this PR in yesterday, finally thinking this was done https://github.com/discourse/discourse/pull/12958 but then a wild performance regression occurred. These are the problem methods: https://github.com/discourse/discourse/blob/1aa20bd681e634f7fff22953ed62d90c2573b331/app/serializers/topic_tracking_state_serializer.rb#L13-L21 Turns out date comparison is super expensive on the backend _as well as_ the frontend. The fix was to just move the `treat_as_new_topic_start_date` into the SQL query rather than using the slower `UserOption#treat_as_new_topic_start_date` method in ruby. After this change, 1% of the total time is spent with the `created_in_new_period` comparison instead of ~20%. ---- History: Original PR which had to be reverted **https://github.com/discourse/discourse/pull/12555**. See the description there for what this PR is achieving, plus below. The issue with the original PR is addressed in https://github.com/discourse/discourse/pull/12958/commits/92ef54f4020111ffacb0f2a27da5d5c2855f9d5d If you went to the `x unread` link for a tag Chrome would freeze up and possibly crash, or eventually unfreeze after nearly 10 mins. Other routes for unread/new were similarly slow. From profiling the issue was the `sync` function of `topic-tracking-state.js`, which calls down to `isNew` which in turn calls `moment`, a change I had made in the PR above. The time it takes locally with ~1400 topics in the tracking state is 2.3 seconds. To solve this issue, I have moved these calculations for "created in new period" and "unread not too old" into the tracking state serializer. When I was looking at the profiler I also noticed this issue which was just compounding the problem. Every time we modify topic tracking state we recalculate the sidebar tracking/everything/tag counts. However this calls `forEachTracked` and `countTags` which can be quite expensive as they go through the whole tracking state (and were also calling the removed moment functions). I added some logs and this was being called 30 times when navigating to a new /unread route because `sync` is being called from `build-topic-route` (one for each topic loaded due to pagination). So I just added a debounce here and it makes things even faster. Finally, I changed topic tracking state to use a Map so our counts of the state keys is faster (Maps have .size whereas objects you have to do Object.keys(obj) which is O(n).) <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2021-06-02 07:06:29 +08:00
:treat_as_new_topic_start_date,
:previous_visit_at,
:seen_notification_id,
:primary_group_id,
:flair_group_id,
:can_create_topic,
:can_create_group,
:link_posting_access,
:external_id,
:top_category_ids,
:hide_profile_and_presence,
:groups,
:second_factor_enabled,
:ignored_users,
:title_count_mode,
:timezone,
:featured_topic,
2020-12-18 23:03:51 +08:00
:skip_new_user_tips,
:do_not_disturb_until,
:has_topic_draft,
:can_review,
def groups
owned_group_ids = GroupUser.where(user_id: id, owner: true).pluck(:group_id).to_set
object.visible_groups.pluck(:id, :name).map do |id, name|
group = { id: id, name: name }
group[:owner] = true if owned_group_ids.include?(id)
group
end
end
def link_posting_access
scope.link_posting_access
end
def can_create_topic
scope.can_create_topic?(nil)
end
2013-02-06 03:16:51 +08:00
def can_create_group
scope.can_create_group?
end
def include_can_create_group?
scope.can_create_group?
end
def read_faq
object.user_stat.read_faq?
end
def any_posts
object.user_stat.any_posts
end
def hide_profile_and_presence
object.user_option.hide_profile_and_presence
end
def enable_quoting
object.user_option.enable_quoting
end
def enable_defer
object.user_option.enable_defer
end
def external_links_in_new_tab
object.user_option.external_links_in_new_tab
end
def dynamic_favicon
object.user_option.dynamic_favicon
end
def title_count_mode
object.user_option.title_count_mode
end
def automatically_unpin_topics
object.user_option.automatically_unpin_topics
end
def should_be_redirected_to_top
object.user_option.should_be_redirected_to_top
end
def redirected_to_top
object.user_option.redirected_to_top
end
def timezone
object.user_option.timezone
end
def can_send_private_email_messages
scope.can_send_private_messages_to_email?
end
def can_send_private_messages
scope.can_send_private_message?(Discourse.system_user)
end
def can_edit
true
end
def can_invite_to_forum
scope.can_invite_to_forum?
end
def include_can_invite_to_forum?
scope.can_invite_to_forum?
end
def no_password
true
end
def include_no_password?
!object.has_password?
end
def include_can_delete_account?
2014-02-14 04:51:19 +08:00
scope.can_delete_user?(object)
end
def can_delete_account
2014-02-14 04:51:19 +08:00
true
end
def include_redirected_to_top?
object.user_option.redirected_to_top.present?
end
def custom_fields
fields = nil
if SiteSetting.public_user_custom_fields.present?
fields = SiteSetting.public_user_custom_fields.split('|')
end
DiscoursePluginRegistry.serialized_current_user_fields.each do |f|
fields ||= []
fields << f
end
if fields.present?
User.custom_fields_for_ids([object.id], fields)[object.id] || {}
else
{}
end
end
def muted_category_ids
categories_with_notification_level(:muted)
end
def regular_category_ids
categories_with_notification_level(:regular)
end
def tracked_category_ids
categories_with_notification_level(:tracking)
end
def watched_category_ids
categories_with_notification_level(:watching)
end
def watched_first_post_category_ids
categories_with_notification_level(:watching_first_post)
end
# this is a weird outlier that is used for topic tracking state which
# needs the actual ids, which is why it is duplicated with muted_tags
def muted_tag_ids
TagUser.lookup(object, :muted).pluck(:tag_id)
end
def muted_tags
tags_with_notification_level(:muted)
end
def tracked_tags
tags_with_notification_level(:tracking)
end
def watching_first_post_tags
tags_with_notification_level(:watching_first_post)
end
def watched_tags
tags_with_notification_level(:watching)
end
def regular_tags
tags_with_notification_level(:regular)
end
def ignored_users
IgnoredUser.where(user: object.id).joins(:ignored_user).pluck(:username)
end
def top_category_ids
omitted_notification_levels = [CategoryUser.notification_levels[:muted], CategoryUser.notification_levels[:regular]]
CategoryUser.where(user_id: object.id)
.where.not(notification_level: omitted_notification_levels)
.order("
CASE
WHEN notification_level = 3 THEN 1
WHEN notification_level = 2 THEN 2
WHEN notification_level = 4 THEN 3
END")
.pluck(:category_id)
.slice(0, SiteSetting.header_dropdown_category_count)
end
2014-06-19 02:04:10 +08:00
def dismissed_banner_key
object.user_profile.dismissed_banner_key
end
def is_anonymous
object.anonymous?
end
def reviewable_count
Reviewable.list_for(object).count
end
def can_review
scope.can_see_review_queue?
end
def mailing_list_mode
object.user_option.mailing_list_mode
end
DEV: Topic tracking state improvements (#13218) I merged this PR in yesterday, finally thinking this was done https://github.com/discourse/discourse/pull/12958 but then a wild performance regression occurred. These are the problem methods: https://github.com/discourse/discourse/blob/1aa20bd681e634f7fff22953ed62d90c2573b331/app/serializers/topic_tracking_state_serializer.rb#L13-L21 Turns out date comparison is super expensive on the backend _as well as_ the frontend. The fix was to just move the `treat_as_new_topic_start_date` into the SQL query rather than using the slower `UserOption#treat_as_new_topic_start_date` method in ruby. After this change, 1% of the total time is spent with the `created_in_new_period` comparison instead of ~20%. ---- History: Original PR which had to be reverted **https://github.com/discourse/discourse/pull/12555**. See the description there for what this PR is achieving, plus below. The issue with the original PR is addressed in https://github.com/discourse/discourse/pull/12958/commits/92ef54f4020111ffacb0f2a27da5d5c2855f9d5d If you went to the `x unread` link for a tag Chrome would freeze up and possibly crash, or eventually unfreeze after nearly 10 mins. Other routes for unread/new were similarly slow. From profiling the issue was the `sync` function of `topic-tracking-state.js`, which calls down to `isNew` which in turn calls `moment`, a change I had made in the PR above. The time it takes locally with ~1400 topics in the tracking state is 2.3 seconds. To solve this issue, I have moved these calculations for "created in new period" and "unread not too old" into the tracking state serializer. When I was looking at the profiler I also noticed this issue which was just compounding the problem. Every time we modify topic tracking state we recalculate the sidebar tracking/everything/tag counts. However this calls `forEachTracked` and `countTags` which can be quite expensive as they go through the whole tracking state (and were also calling the removed moment functions). I added some logs and this was being called 30 times when navigating to a new /unread route because `sync` is being called from `build-topic-route` (one for each topic loaded due to pagination). So I just added a debounce here and it makes things even faster. Finally, I changed topic tracking state to use a Map so our counts of the state keys is faster (Maps have .size whereas objects you have to do Object.keys(obj) which is O(n).) <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2021-06-02 07:06:29 +08:00
def treat_as_new_topic_start_date
object.user_option.treat_as_new_topic_start_date
end
def skip_new_user_tips
object.user_option.skip_new_user_tips
end
def include_primary_group_id?
object.primary_group_id.present?
end
def external_id
object&.single_sign_on_record&.external_id
end
def include_external_id?
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978) The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense. This commit aims to: - Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_` - Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices - Copy `site_settings` database records to the new names - Rename relevant translation keys - Update relevant translations This commit does **not** aim to: - Rename any Ruby classes or methods. This might be done in a future commit - Change any URLs. This would break existing integrations - Make any changes to the protocol. This would break existing integrations - Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately The risks are: - There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical. - If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working. A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 18:04:33 +08:00
SiteSetting.enable_discourse_connect
end
def second_factor_enabled
object.totp_enabled? || object.security_keys_enabled?
end
def featured_topic
object.user_profile.featured_topic
end
def has_topic_draft
true
end
def include_has_topic_draft?
Draft.has_topic_draft(object)
end
2013-02-06 03:16:51 +08:00
end