Models

Admins can create Announcements, which are text strings intended to be shown to all users. All announcements have a ‘display until’ time, and are considered ‘active’ until their display until time expires.

Announcement IDs are ints, and increase with each announcement created. The User model stores the highest Announcement ID the user has seen.

Announcements are global, and are retrieveable while logged out. However, endpoints returning announcement data will only return all active announcements for logged-out users. Logged-in users will additionally get data indicating which announcements are unread. Clients may implement local solutions for determining which announcements are unread for logged-out users.

A boardgame in the Games Library.

Categories are used to organize Twit-arr Forums into a managable structure. All Forums belong to a single Category.

Each Category has a minimum userAccessLevel required to view the Category or view forums in the Category. Each Category also has a minimum userAccessLevel required to create new forums in the Category.

Every day during the cruise, there’s a theme. This model lets us store the themes for each day, with a bit of text explaining the theme and an image related to the theme somehow.

For an 8 day cruise, there shouldn’t be more than ~10 of these records. Each day of the cruise tends to have an ‘officall’ theme day, and it might be appropriate to add unofficial themes for a day or two before embarkation?

An Event on the official schedule, imported from sched.com’s .ics format.

An individual post within a FriendlyFez discussion. A FezPost must contain text content and may also contain image content, unless the Fez is of type FezType.closed, in which case the post may not contain images.

When a Forum is edited, a ForumEdit is created to save the previous title text.

This is done for accountability purposes and the data collected is intended to be viewable only by users with an access level of .moderator or above.

When a ForumPost is edited, a ForumPostEdit is created and associated with the post.

This is done for accountability purposes and the data collected is intended to be viewable only by users with an access level of .moderator or above.

An individual post within a Forum. A ForumPost must contain text content and may also contain image content.

Posts have a moderationStatus that moderators can change to perform moderation actdions.

When a post is edited, a ForumPostEdit is created to save the pre-edit state of the post.

A collection of ForumPosts on a single topic. Only the forum’s creator or a moderator can edit a forum’s title. Only moderators can can change a forum’s moderationStatus.

When the TEXT FIELDS of a FriendlyFez are edited, a FriendlyFezEdit is created to save the previous values of its text fields. Edits that only modify other fields of a fez–start/end time, type of fez, min/max number of participants–do not cause a FriendlyFezEdit to be created.

This is done for accountability purposes and the data collected is intended to be viewable only by moderators.

A FriendlyFez (Fez for short) is a multi person chat facilty.

Broadly speaking, Fezzes may be open or closed, chosen at creation time.

• Open fezzes generally have a publicly stated purpose, and may be for an event at a specific time and place. Open fezzes allow users to join and leave the fez at any time. Open fezzes may have posts with images, and can get moderated by mods. There is a search API for finding and joining public fezzes.
• Closed fezzes have a membership set at creation time (by the fez creator), and cannot have images in posts. Closed fezzes are very similar to V2’s Seamail facility.

Considered but not yet built are semi-open fezzes:

• A semi-open fez would allow users to join after creation, but either the creator would have to invite new members or perhaps users could join via an invite link. Semi-open fezzes would not be searchable, would not be moderated, could not have images. Importantly, semi-open fezzes would indicate their semi-open state to their members, so that current members would know the membership list could change. New members to a semi-open fez would be able to read all past messages.

This is the object a Karaoke Manager makes when they log a karaoke performance in the Karaoke Lounge.

The played song is related to a song in the Karaoke Library, and the Manager records the name(s) of the karaoke singer(s). A timestamp is added automatically.

A song in the Karaoke Jukebox. The Jukebox has ~25000 songs; rather too many to let users browse without searching. For Heroku deploys there’s an alternate import file that only import ~1000 songs. This is due to Heroku’s free tier limiting us to 10000 database rows.

Each time a moderator performs a moderation action–editing, locking, or deleting a post, forum, or fez, changing a user’s access level, issuing a temp quarantine, or other moderation-only activities, we log the action by creating one of these records in the database..

The data collected may only be viewed by moderators. The intent is to make it easier for mods to coordinate.

When a UserProfile is edited, a ProfileEdit is created and associated with the profile. The ProfileEdit records the state of the profile just before the edit occurred.

This is done for accountability purposes and the data collected is intended to be viewable only by users with an access level of .moderator or above.

A RegistrationCode associates a specific pre-generated code with a specific User account, as well as tracks when the association occurred.

To maintain accountability for conduct on Twit-arr, a user must first register their primary account before gaining the ability to post any content, either public or private. This is done with a unique registration code provided to each participant by Management. The full set of codes (which contain no identifying information) is provided to the Twit-arr admins prior to the event, and they are loaded by a Migration during system startup.

Twit-arr moderation relies in part on user-submitted reports of content and/or behavior which does not conform to community standards. A Report can be submitted for Moderator review on any of: an individual Twarrt or ForumPost, an entire Forum, a FezPost, or a User (such as for general behavioral pattern, or their profile contents).

The .submitterID is always the user’s primary user ID. An individual post can only be reported once per primary user. There is no per user restriction on the number of reports of a particular Forum or User.

The .reportedID field is a string value, because the entity being reported may have either a UUID or an integer based ID, which is determined via the .reportType.

The lifecycle flow of Reports is:

• Created by submitter
• Viewed by a moderator in a list of open reports
• Moderator takes the report (handledBy is set to the moderator’s UUID). Other mods should be able to see the report is being handled.
• Moderator modifies content, quarantines content, warns user, bans user, or takes some other action.
• Moderator fills in actionTaken field and closes the report.

A TimeZoneChange model says that at a specific UTC Date the ship will adopt a given timezone, specified by abbreviation and UTC offset.

The ‘current’ TimeZoneChange is the one with the a start date in the most recent past. The timezone indicated by the current TimeZoneChange is in force until the next (in Date order) TimeZoneChange becomes current.

A Token model associates a randomly generated string with a User.

A Token is generated upon each login, and revoked by deletion upon each logout. The .token value is used in between those events in an HTTP Bearer Authorization header field to authenticate the user sending API requests. There is no identifying user info in a .token; the association to a specific User is done internally on the API server through this model.

When a Twarrt is edited, a TwarrtEdit is created and associated with the twarrt.

This is done for accountability purposes and the data collected is intended to be viewable only by users with an access level of .moderator or above.

An individual post in the Twitarr stream. Posts must contain text content, and may also contain images.

Twarrts are content that can be quarantined or locked by moderators. A quarantined twarrt will have its contents replaced with a quarantine message, and will not have any images. A locked twarrt can only be modified by moderators. When edited, twarrts create edit records showing previous state for moderation purposes.

V2 of Twitarr (and, actual Twitter) have tweet replies that work as a directed acyclic graph. Any tweet can be created as a reply to an existing tweet, a tweet can have multiple direct reply tweets, and a tweet can be both a reply to another tweet and the target of other replies. V3 doesn’t work that way. A new twarrt replying to a twarrt not already in a Reply Group creates a Reply Group, and both the replied–to and reply twarrt have their replyGroup set to the ID of the replied-to twarrt. A reply to a twarrt already in a Reply Group gets added to the Reply Group.

This means that any twarrt that has a non-null replyGroup has a thread can can be retrieved. It also means that replies are one level deep–a reply to a reply is not considered differernt than a 2 replies to a single twarrt.

A UserNote is intended as a free-form text field that will appear on a UserProfile, in which the viewing User can make notes about the profile’s user.

It is not visible to the profile’s owner nor to any other user; it is for the viewing user’s use only. In other words, different users viewing the same profile will each see their own viewer-specific UserNote text.

A UserNote is intended as a free-form test field that will appear on a UserProfile, in which the viewing User can make notes about the profile’s user.

It is not visible to the profile’s owner nor to any other user; it is for the viewing user’s use only. In other words, different users viewing the same profile will each see their own viewer-specific UserNote text.

All accounts are of class User.

The terms “account” and “sub-account” used throughout this documentatiion are all instances of User. The terms “primary account”, “parent account” and “master account” are used interchangeably to refer to any account that is not a sub-account.

A primary account holds the access level, verification token and recovery key, and all sub-accounts (if any) inherit these three credentials.

.id and .parentID are provisioned automatically, by the model protocols and UsersController account creation handlers respectively. .createdAt, .updatedAt and .deletedAt are all maintained automatically by the model protocols and should never be otherwise modified.