discourse/app/serializers/current_user_serializer.rb

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

282 lines
6.7 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
2013-02-05 14:16:51 -05:00
class CurrentUserSerializer < BasicUserSerializer
include UserTagNotificationsMixin
include UserSidebarMixin
2013-02-05 14:16:51 -05:00
2013-02-25 11:42:20 -05:00
attributes :name,
:unread_notifications,
:unread_high_priority_notifications,
:all_unread_notifications_count,
:read_first_notification?,
2013-02-25 11:42:20 -05:00
:admin?,
:notification_channel_position,
:moderator?,
:staff?,
:whisperer?,
:title,
:any_posts,
:trust_level,
:can_send_private_email_messages,
:can_send_private_messages,
:can_edit,
:can_invite_to_forum,
:no_password,
:can_delete_account,
:custom_fields,
2014-06-18 14:04:10 -04:00
:muted_category_ids,
:indirectly_muted_category_ids,
:regular_category_ids,
:tracked_category_ids,
:watched_first_post_category_ids,
:watched_category_ids,
:watched_tags,
:watching_first_post_tags,
:tracked_tags,
:muted_tags,
:regular_tags,
:dismissed_banner_key,
:is_anonymous,
:reviewable_count,
:unseen_reviewable_count,
:new_personal_messages_notifications_count,
:read_faq?,
:previous_visit_at,
:seen_notification_id,
:primary_group_id,
:flair_group_id,
:can_create_topic,
:can_create_group,
:link_posting_access,
:external_id,
:associated_account_ids,
:top_category_ids,
:groups,
:second_factor_enabled,
:ignored_users,
:featured_topic,
2020-12-18 10:03:51 -05:00
:do_not_disturb_until,
:has_topic_draft,
:can_review,
:draft_count,
:pending_posts_count,
:status,
:grouped_unread_notifications,
:display_sidebar_tags,
:sidebar_tags,
:sidebar_category_ids,
:sidebar_sections,
:new_new_view_enabled?,
DEV: Upgrade search-menu to glimmer (#20482) # Top level view This PR is the first version of converting the search menu and its logic from (deprecated) widgets to glimmer components. The changes are hidden behind a group based feature flag. This will give us the ability to test the new implementation in a production setting before fully committing to the new search menu. # What has changed The majority of the logic from the widget implementation has been updated to fit within the context of a glimmer component, but it has not fundamentally changed. Instead of having a single widget - [search-menu.js](https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/widgets/search-menu.js) - that built the bulk of the search menu logic, we split the logic into (20+) bite size components. This greatly increases the readability and makes extending a component in the search menu much more straightforward. That being said, certain pieces needed to be rewritten from scratch as they did not translate from widget -> glimmer, or there was a general code upgraded needed. There are a few of these changes worth noting: ### Search Service **Search Term** -> In the widget implementation we had a overly complex way of managing the current search term. We tracked the search term across multiple different states (`term`, `opts.term`, `searchData.term`) causing headaches. This PR introduces a single source of truth: ```js this.search.activeGlobalSearchTerm ``` This tracked value is available anywhere the `search` service is injected. In the case the search term should be needs to be updated you can call ```js this.search.activeGlobalSearchTerm = "foo" ``` **event listeners** -> In the widget implementation we defined event listeners **only** on the search input to handle things such as - keyboard navigation / shortcuts - closing the search menu - performing a search with "enter" Having this in one place caused a lot of bloat in our logic as we had to handle multiple different cases in one location. Do _x_ if it is this element, but do _y_ if it is another. This PR updates the event listeners to be attached to individual components, allowing for a more fine tuned set of actions per element. To not duplicate logic across multiple components, we have condensed shared logic to actions on the search service to be reused. For example - `this.search.handleArrowUpOrDown` - to handle keyboard navigation. ### Search Context We have unique logic based on the current search context (topic / tag / category / user / etc). This context is set within a models route file. We have updated the search service with a tracked value `searchContext` that can be utilized and updated from any component where the search service is injected. ```js # before this.searchService.set("searchContext", user.searchContext); # after this.searchService.searchContext = user.searchContext; ``` # Views <img width="434" alt="Screenshot 2023-06-15 at 11 01 01 AM" src="https://github.com/discourse/discourse/assets/50783505/ef57e8e6-4e7b-4ba0-a770-8f2ed6310569"> <img width="418" alt="Screenshot 2023-06-15 at 11 04 11 AM" src="https://github.com/discourse/discourse/assets/50783505/2c1e0b38-d12c-4339-a1d5-04f0c1932b08"> <img width="413" alt="Screenshot 2023-06-15 at 11 04 34 AM" src="https://github.com/discourse/discourse/assets/50783505/b871d164-88cb-405e-9b78-d326a6f63686"> <img width="419" alt="Screenshot 2023-06-15 at 11 07 51 AM" src="https://github.com/discourse/discourse/assets/50783505/c7309a19-f541-47f4-94ef-10fa65658d8c"> <img width="424" alt="Screenshot 2023-06-15 at 11 04 48 AM" src="https://github.com/discourse/discourse/assets/50783505/f3dba06e-b029-431c-b3d0-36727b9e6dce"> <img width="415" alt="Screenshot 2023-06-15 at 11 08 57 AM" src="https://github.com/discourse/discourse/assets/50783505/ad4e7250-040c-4d06-bf06-99652f4c7b7c">
2023-06-16 10:24:07 -04:00
:experimental_search_menu_groups_enabled?
delegate :user_stat, to: :object, private: true
delegate :any_posts, :draft_count, :pending_posts_count, :read_faq?, to: :user_stat
has_one :user_option, embed: :object, serializer: CurrentUserOptionSerializer
def sidebar_sections
SidebarSection
.public_sections
.or(SidebarSection.where(user_id: object.id))
.includes(:sidebar_urls)
.order("(section_type IS NOT NULL) DESC, (public IS TRUE) DESC")
.map { |section| SidebarSectionSerializer.new(section, root: false) }
end
def groups
owned_group_ids = GroupUser.where(user_id: id, owner: true).pluck(:group_id).to_set
object
.visible_groups
.pluck(:id, :name, :has_messages)
.map do |id, name, has_messages|
group = { id: id, name: name, has_messages: has_messages }
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-05 14:16:51 -05:00
def can_create_group
scope.can_create_group?
end
def include_can_create_group?
scope.can_create_group?
end
def can_send_private_email_messages
scope.can_send_private_messages_to_email?
end
def can_send_private_messages
scope.can_send_private_messages?
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-13 15:51:19 -05:00
scope.can_delete_user?(object)
end
def can_delete_account
2014-02-13 15:51:19 -05:00
true
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 indirectly_muted_category_ids
CategoryUser.indirectly_muted_category_ids(object)
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
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-18 14:04:10 -04:00
def dismissed_banner_key
object.user_profile.dismissed_banner_key
end
def is_anonymous
object.anonymous?
end
def can_review
scope.can_see_review_queue?
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 05:04:33 -05:00
SiteSetting.enable_discourse_connect
end
def associated_account_ids
values = {}
object.user_associated_accounts.map do |user_associated_account|
values[user_associated_account.provider_name] = user_associated_account.provider_uid
end
values
end
def include_associated_account_ids?
SiteSetting.include_associated_account_ids
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
2022-05-27 05:15:14 -04:00
def include_status?
SiteSetting.enable_user_status && object.has_status?
2022-05-27 05:15:14 -04:00
end
def status
UserStatusSerializer.new(object.user_status, root: false)
end
def unseen_reviewable_count
Reviewable.unseen_reviewable_count(object)
end
2013-02-05 14:16:51 -05:00
end