Enumerations

Convenience LibGd Format

  • Declaration

    Swift

    public enum ExportableFormat : ExportableFormatter
  • The type of FriendlyFez.

    See more

    Declaration

    Swift

    public enum FezType : String, CaseIterable, Codable
  • Represents errors that can be thrown within the SwiftGD module.

    • invalidFormat: Image raster format mismatch on import/export
    • invalidImage: Contains the reason this error was thrown.
    • invalidColor: Contains the reason this error was thrown.
    • invalidMaxColors: Asserts sane values for creating indexed Images
    See more

    Declaration

    Swift

    public enum GDError : Swift.Error
  • Internally, the Image Handler stores images at multiple sizes upon image upload. The exact sizes stored for each sizeGroup may vary based on ImageUsage. Request images at roughly the size you need.

    See more

    Declaration

    Swift

    enum ImageSizeGroup : String
  • The type of model for which an ImageHandler is processing. This defines the size of the thumbnail produced.

    See more

    Declaration

    Swift

    enum ImageUsage : String
  • The type of “like” reaction that a user can apply to a ForumPost or Twarrt. Only positive reactions are provided in swiftarr.

    See more

    Declaration

    Swift

    public enum LikeType : String, Codable
  • Describes the type of action a moderator took. This enum is used both in the ModeratorAction Model, and in several Moderation DTOs. Be careful when modifying this. Not all ModeratorActionTypes are applicable to all ReportTypes.

    See more

    Declaration

    Swift

    public enum ModeratorActionType : String, Codable
  • A type of event that can change the value of the global notification handler’s UserNotificationData result.

    When certain database-mutating events occur, the notification bookkeeping methods need to be called to keep our cached notification counts up to date. The notification counts themselves are database-denormalizing, but they’re a cache intended to improve the performance of the global notification method.

    How notifications are stored in Redis:

    • Announcements: ActiveAnnouncementIDs holds announcement IDs for all active announcements, Its updated frequently to catch expiring announcements.
    • Mentions: Fields twarrtMention and forumMention in hash-valued key NotificationHash-\(userID) hold the total number of @mentions for each user–this should be equal to the # of results a text search for @<username> will return. Counts are updated on each post, post edit, and post deletion.
    • Alertwords: All alertwords by all users are kept in a sorted set keyed by alertwords. The value for each entry in the set is the number of users watching on that alertword. When someone posts, we get all fields in alertwords with values > 0. We then intersect the words in the post with the words from alertwords. For any words in the intersection, we get the set-valued key alertwordusers-\(word) to get the set of users watching on that particular word. We then increment the count of the field alertwordTweet-\(word) in key NotificationHash-\(userID).
    • Fez Posts/Seamails: When a post is created, we increment a field named with the fezzes’ ID in the UnreadFezzes-\(userID) or UnreadSeamails-\(userID) key. When a post is deleted, we decrement the same field, only for users that haven’t seen the post (their unseen count is less than how far back the deleted post is).
    • Next Event Time: Every time an event is followed/unfollowed, we calculate the time of the next event in the followed list, storing that in the nextFollowedEventTime field in NotificationHash-\(userID).

    How notifications are marked ‘viewed’ in Redis:

    • Announcements: Each user stores the # of their highest-read announcement in the announcement field of the hash-valued key NotificationHash-\(userID). The number of announcements with IDs > the highest-read announceemnt are ‘new’ to that user. This means an announceement could appear and then expire unseen by a user, and their unseen count would continue to be correct.
    • Mentions: The # of mentions the user has viewed are stored in twarrtMention_viewed in the NotificationHash-\(userID) key, and set equal to the relevant @mention count when a user’s own mentions are viewed (that is, twarrts/posts are requested with a query of mentionSelf or similar).
    • Alertwords: Similar to Mentions; the # of alertword hits that have been viewed is stored in alertwordTweet-\(word)_viewed. The difference between this field and alertwordTweet-\(word) equals the number of new, unseen alertword hits. The _viewed field is set equal to the count field upon viewing hits.
    • Fez Posts: When the fez is viewed (more corectly, the getSingleFez api call is made), we set the # of unseen posts for the fez to 0.
    • Next Event Time: Never gets deleted, but can get expired when the current time is > the event time.
    See more

    Declaration

    Swift

    enum NotificationType
  • The type of entity being reported in a Report.

    See more

    Declaration

    Swift

    public enum ReportType : String, Codable
  • Names of clients that consume the Swiftarr client API. Used in the SettingsAppFeaturePair struct. Clients: Be sure to anticipate server values not listed here.

    See more

    Declaration

    Swift

    public enum SwiftarrClientApp : String, Content, CaseIterable
  • Functional areas of the Swiftarr API. Used in the SettingsAppFeaturePair struct. Clients: Be sure to anticipate server values not listed here.

    See more

    Declaration

    Swift

    public enum SwiftarrFeature : String, Content, CaseIterable
  • All API endpoints are protected by a minimum user access level. This enum structure MUST match the values in CreateCustomEnums in SchemaCreation.swift as this enum is part of the database schema. This enum is also sent out in several Data Transfer Object types. Think very carefully about modifying these values.

    See more

    Declaration

    Swift

    public enum UserAccessLevel : String, Codable, Sendable
    extension UserAccessLevel: Comparable
  • UserRole is a simple role-based access control mechanism mostly used for elevating ‘verified’ users to have specific extra access. UserRole is therefore an access model that works in addition to Twitarr’s priority access model (see UserLevel). With UserLevlels, each increasing access level is a superset of access provided by the previous level. Roles allow multiple users to each extend the verified permissions without one of the extensions always being a superset of the other.

    This implementation is not a full RBAC. Instead: - Each user may have multiple roles - A db object or API call that requires a role to use must test that the requesting user has the proper role. - Roles implicitly define permissions; there is no facility to add/remove permissions from roles. - There is no role hierarchy. An operation X that allows X_User and X_Manager to access it must test for both roles explicitly. - Ideally, a DB object that requires a role to access should only require one role be stored for it. - In general, a nil value for a DB object’s requiredRole should mean no special role is required to access it. - Moderators and above should usually have access to role-protected content; without us having to add a bunch of roles to each moderator user.

    See more

    Declaration

    Swift

    public enum UserRoleType : String, CaseIterable, Codable, Sendable