discourse/app/serializers/notification_serializer.rb

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

52 lines
950 B
Ruby
Raw Normal View History

# frozen_string_literal: true
2013-02-05 14:16:51 -05:00
class NotificationSerializer < ApplicationSerializer
attributes :id,
:user_id,
:external_id,
:notification_type,
2013-02-07 10:45:24 -05:00
:read,
:high_priority,
2013-02-07 10:45:24 -05:00
:created_at,
2013-02-05 14:16:51 -05:00
:post_number,
:topic_id,
:fancy_title,
2013-02-05 14:16:51 -05:00
:slug,
:data,
:is_warning
2013-02-05 14:16:51 -05:00
2013-02-07 10:45:24 -05:00
def slug
2013-02-05 14:16:51 -05:00
Slug.for(object.topic.title) if object.topic.present?
end
def is_warning
object.topic.present? && object.topic.subtype == TopicSubtype.moderator_warning
end
def include_fancy_title?
object.topic&.fancy_title
end
def fancy_title
object.topic.fancy_title
end
def include_is_warning?
is_warning
end
2013-02-05 14:16:51 -05:00
def data
object.data_hash
end
def external_id
object.user&.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
2013-02-05 14:16:51 -05:00
end