Settings

When an administrator renames a list value, a severity level or an incident role, including a rename that changes only capitals, spacing or hidden characters, EA Sphere moves every record, degradation and acknowledgment that holds it to the new name as part of accepting the settings. When there are too many to move at once, it finishes right after, at the next save or at the weekly maintenance: each record's history line is credited to the administrator who renamed that value, no record gets the line twice, and a record someone saves before the move reaches it takes the new name with its line. If the administrator's Atlassian account is closed and erased before the move finishes, the remaining lines are credited to EA Sphere.

Until the move is finished, a settings save that adds the old name again is refused, with a message that the value was renamed a moment ago and its records are still being moved, and removing the new name is refused, with a message that it is still being given to the records of its old name. A save that renames a list value or a severity level and adds its old name again is refused too, with a message to save the rename first; an incident role renamed in one row may keep its old name in another.

Meanwhile the page shows, lists, filters, exports and compares every record and degradation under the new names at once: in forms, Learning and an open briefing, the reference lists' counts, reports and their choices, filters and CSV import alike. A filter or report choice set to a value that is no longer on its list is cleared, and so is one set to a record that was deleted or a recovery tier that was removed, so a report never appears empty while its filter reads All; Work history's Selected on the map filter is cleared when its record is deleted, rather than moving to another record. An administrator's own rename shows at once on their page, in records, filters, briefings and the Reference lists editor's counts, while the save is on its way; if EA Sphere does not record it, the page goes back to what it was, the administrator's own acknowledgments included, and filters and an open briefing go back only if they are still as the rename left them. Saving a form changes such a value only if you change it, a change you make to it, such as a new owner, data type or cause, stands with your history line, and a record anyone saves gets one rename line, credited to the administrator who renamed, never to the person whose save carried it. The message after saving the reference lists says that records using renamed values are being updated, until they are.

The settings and team choices that name the value are renamed with it, acknowledgments keep their completion dates, and the rename is also applied to saves from pages opened before it. Notices, updates and acknowledgments recorded while a rename is being moved are never dropped by the move, even when older updates are archived meanwhile, and none is kept twice; an acknowledgment recorded while a team or role is renamed is stored under the new name, so a team created later under the old name never counts the person as a member or credits them with its briefing; a degradation resolved meanwhile stays resolved, with its new names.

When two administrators rename the same value at once, the later rename stands, as one entry. A name that was renamed and is later added to the list again once the move is finished is a new value: nothing is moved to it. A value typed in a record or degradation form that matches a list value apart from case, spacing or hidden characters is stored in the list's own spelling. CSV import matches values the same way and adds new ones to these lists; values are separated by semicolons. A value renamed in Settings is imported under its new name, in any capitals, and nothing is added to the lists for it: to use an old name again, add it in Settings first. While the rename is being moved, an existing record whose row names the old value gets no change beyond the rename's own history line.

Saving settings saves only the sections you changed, so another administrator's changes to other sections are kept. While EA Sphere saves them, Save shows Saving…, and a second Save or Discard waits until it is done. Leaving Settings while a save is under way asks nothing; the save completes. Once the save is accepted, the form shows the stored settings. If EA Sphere refuses the save or cannot record it, for example because the connection is lost, the form stays exactly as you sent it, renames included, and the message says that the settings were not saved, with the reason when there is one; meanwhile the rest of the page shows the settings EA Sphere last accepted, reading them again until it can. A save that is not recorded moves no records to renamed values. Tier definitions and the reference lists are saved the same way.

List values, severity levels, audiences, sender groups, recovery tiers and change freezes are stored without invisible characters and compared as record names are; a name listed twice is caught before saving, with a message naming it, except that a change freeze may share its name with another that has different dates. When two administrators add an audience, severity level, sender group or recovery tier of the same name at the same moment, the later save is refused if the details differ, and the message says that the settings were not saved and that the name was added by someone else a moment ago. The form then shows both your row and theirs to review, and a save with both still there is stopped with a message that the name appears twice. With the same details, the name is kept once. An incident role may be listed more than once, for example a lead and a deputy for the same role; the role briefing shows every row, and a row repeated exactly is kept once. Each row is kept as a row of its own, so two administrators can edit the lead and the deputy at once without either change landing on the other row; a role named again in another case or spacing is stored in the first row's spelling.