v0.10.2

Added

• A member's profile shows "Invited by" to viewers holding invites_manage (#411, stellar-api#849). It links to the inviter's profile, or says Nobody for a member no one invited. The api withholds the field from anyone else, so the row is hidden for them.
• The registration log shows each account's inviter and flags a shared IP (#412, stellar-api#850).
  • Each cell shows the new account's value with its inviter's beneath, muted: name, email, rank, registration date and IP.
  • Each IP carries how many accounts hold it now.
  • A row whose account and inviter share an IP is highlighted and marked Same IP.
  • The column is now Current IP, since both addresses are where each account is now, not where it registered from.
• The invite form shows its staff note only to holders of invites_note (#413, stellar-api#851).
  • Its label now says the note is added to the invitee's moderation notes when they register.
  • The api ignores a note from anyone else, so the field is hidden from them and the form sends none.
  • The note now takes up to 1000 characters, the api's limit, where the input stopped at 255.
• "Can't find your community?" now opens a pre-filled Staff PM asking staff to create one (#100).
  • The link is on the contribute form and, new, under the list on the Communities page. It read "Submit a request." and went to the release request list, which can't create a community.
  • It opens /inbox/staff/new?template=community-request. The subject starts with a fixed [Create a Community Request] tag, and the member types only their line after it.
  • The message greets the site's staff by name (from GET /rules/tree, or "Hey there staff," when that can't be read) and asks for the community's name, what it would hold, and why the member would lead it. It is signed with their username.
  • Staff create the community in Community Manager with the member as leader. A request flow that does this on approval is stellar-api#890.
• ?notheme=1 turns member themes off for the tab, so a stylesheet can't lock a member out (#449).
  • Load any page with it, such as /?notheme=1, and no Personal, Registry or registry theme renders in that tab until it closes. The member can then open Settings (Edit) and switch the theme away. A banner says why the page looks plain, and its Turn themes back on button restores the theme. No theme is loaded while the banner shows, so a theme can't hide it.
  • It's for a sheet whose CSS hides the control needed to switch away from it. Staff can paste the link into a reply.
  • The cold-load pre-apply script honours it, so the theme doesn't flash in first. The chosen theme is kept, so turning themes back on, or another tab, still finds it.
• Members can write, edit and delete their own stylesheets (#450, part of #108).
  • My stylesheets (/stylesheets, linked from Settings' Site Stylesheet section) lists your sheets with the space they use: "3 of 5 stylesheet spaces used", or "(no limit)". At the cap, or for a class without spaces, New stylesheet is disabled and says why.
  • The editor takes a name and the CSS, up to 100,000 characters, with a live count. A .css file can be read into the field; nothing is uploaded.
  • When the api refuses a sheet, every violation it found is listed under the field.
  • Saving an edit says it updates the sheet for everyone who adopted it. Deleting frees a space, and the confirmation says adopters keep the sheet until they switch away.
  • Adopting someone's sheet from its page is the next slice (#451).
• Every stylesheet has a page a member can share, read and adopt (#451; with #449 and #450 this completes #108).
  • /stylesheets/{id} shows the sheet's name, its CSS read-only, a link to its author's profile, and Adopt. Its author also sees Edit. The page's address is the link to share; there's no gallery.
  • Adopting says "Adopted — your site now uses {name}", and the site switches to it straight away. The sheet already in use shows In use instead.
  • A missing or deleted sheet says "This stylesheet isn't available".
  • On My stylesheets, a sheet's name now opens its page, with Edit beside it.
  • In Settings, the Registry option says "None adopted yet — open a stylesheet's page to adopt it", or links to the adopted sheet's page.

Changed

• On a community's page, only its leader and staff see the curator controls (#457, stellar-api#895). The api now refuses a curator who isn't the leader when they add or remove another curator, so their Make Curator and Demote buttons are gone.
  • A curator who isn't the leader gets a Step down button on their own row instead. It asks first, because it ends their member management at once, and it says whether it worked.
  • The leader's row has no Demote for anyone, because the api refuses removing the leader as a curator. A leader is reassigned or cleared in Community Manager.
  • Member Add and Remove are unchanged: curators and staff still see them.

Fixed

• A community's member and curator controls say when a write fails (#464, part of #456). Adding or removing a member, and making or demoting a curator, ignored the api's answer. Each now shows the api's message, such as that a curator has to lose that role before being removed as a member, and a refused add keeps the typed user ID. With this, every write in the ui reports its failure, and mutations:check has nothing left in its baseline.

• The staff tools say when a write fails (#463, part of #456). Seven writes ignored the api's answer. Each now shows the api's message:

  • Global Notices: a refused notice cleared the form as if it had been sent, and now keeps it; a failed delete did nothing visible;
  • Tag Aliases: a refused edit closed the row as if it had saved, and now stays open; a failed delete did nothing visible;
  • the deletes on Album of the Month and Do Not Contribute, and removing an artist from Vanity House.

• Messages, notifications and logout say when a write fails (#462, part of #456). Nine writes ignored the api's answer. Each now shows the api's message:

  • the inbox: a failed bulk action cleared the selection as if it had worked, and now keeps it; a single delete did nothing visible;
  • a conversation: sticky, mark unread and delete. A failed delete went back to the inbox as if it had worked, and now stays;
  • the notification corner: mark all read and dismiss; and dismissing a global notice.
  • Logout signs out only once the server has. A failed logout used to clear the session here and go to the login page while the session cookie still worked, so a reload signed back in. It now keeps the session and says it couldn't sign out.

• The forum and comments say when a write fails (#461, part of #456). Ten writes ignored or swallowed the api's answer. Each now shows the api's message, and an edit or comment keeps what was typed:

  • on a thread: lock, sticky, subscribe, catch up, poll vote, and moving it to the Trash;
  • on a post: a failed edit closed the editor as if it had saved, and a failed delete did nothing visible;
  • on comments: a refused comment kept its text but said nothing, and a failed delete did nothing visible.

• The admin panels say when a save or delete fails (#460, part of #456). Twelve writes ignored the api's answer. A failed create cleared its form and a failed edit closed its row as if they had worked; a failed delete or dismiss did nothing visible. Each now shows the api's message, and a form keeps what was typed:

  • the forum category and forum managers: create, edit and delete;
  • the News Manager: post and delete, for announcements and blog entries;
  • the User Rank Manager's delete, and the ModBar's setup-checklist dismiss.

• Community Manager's edit row stays open when a save fails, and says why (#456). The save ignored the api's answer and closed the row either way, so a refused save looked like it had worked, with nothing saved. It now shows the api's message and keeps what was typed, including the new refusal to leave an invite-only or closed community without a leader (stellar-api#892).

• An emptied donor rank colour or badge now clears (#437). Saving an edited donor rank sent each as value || undefined, and the api leaves an undefined field alone, so the save reported success and kept the old value. An edit now sends both as staff left them, and '' clears. Creating a rank still omits an empty field, so the api's defaults apply (a new rank's badge is ♥).

• The stylesheet manager's user-count note now gives the real reasons a count can differ from what members see (#203). It blamed an external stylesheet URL on a registry row, which can no longer happen. It now says the count is members whose saved selection is the stylesheet, disabled accounts included; that a member's Personal or Registry stylesheet shows instead; and that a stylesheet with no CSS URL adds no styling.