ulsklyc/yuvomi v2.91.0

on GitHub

Changed

• Every "administrators only" refusal of the API has the same answer. Routes that only an
  administrator may use refused everyone else with one of four texts ("Permission denied.",
  "Admin access required.", "Not authorized.", and one of its own for the member order), most
  of them without a reason. They now all answer 403 with
  { "error": "Admin access required.", "code": 403, "reason": "admin_required" }. A signed-in
  device gets reason: "device_credential" at every one of these routes, where some of them
  used to send the plain text. API clients that compared the text should read the reason
  instead. Who may use a route has not changed, and the web app shows the same sentence as
  before.
• Four household settings are for administrators only. The currency, the app name, the
  housekeeping payment tasks and the default length of new events count for the whole
  household, but every member could change them through the API. A member who sends
  currency, app_name, housekeeping_payment_tasks or calendar_default_duration to
  PUT /api/v1/preferences now gets 403 with reason: "admin_required", also for an invalid
  value, which used to answer 400, and nothing of that request is saved. Every member still
  reads all four. In the web app members never saw these controls; on the Appearance page they
  now see the household currency as a read-only row.

Fixed

• The backup schedule shows the same time as the next backup. On a server running in
  another time zone than the household, the backup card said "Daily at 02:00" above "Next
  backup 03:00" for the same run. The server now names the zone its schedule runs in, and the
  schedule reads its time, weekday and day from the next run in the household's time zone;
  where that would not hold for every run, for example shortly before only one of the two
  zones changes to summer time, it shows the configured value (BACKUP_SCHEDULE=0 2 * * *)
  instead.
• A wall display reads only the tasks the whole household sees. The task list, a single
  task with its subtasks, its comments, its linked documents, its history, the household's
  completion feed, the tag lists, the task parts of the overview and the task named by a
  points entry (GET /api/v1/tasks, /tasks/:id, /tasks/:id/comments,
  /tasks/:id/documents, /tasks/:id/completions, /tasks/completions, /tasks/tags,
  /tasks/meta/options, /dashboard without audience=household, /rewards/ledger) asked a
  paired display the same question as a person, so a task or subtask shared only with its
  assignees would show on the wall if the display itself was assigned, while ticking it off
  there answered "not found". Every one of these reads now follows the same wall rule: such a
  task answers "not found" like an unknown one, also where a household task answers "no
  access to documents", and the list, its subtask counts, the feeds, the tags, the overview
  with its counts and countdowns leave it out, also for every earlier instance of a repeating
  task; a points entry keeps its row and its points, only without the task's name. Nothing
  changes for people. In the app this state could not be reached: a display is never offered
  as an assignee, and the server refuses it as one.
• A wall display reads only the events the whole household sees. The calendar, the next
  events, the event search, a single event, the event count and the synced calendars of the
  calendar list, and the event parts of the overview without audience=household showed a
  display an event shared only with its assignees if the display itself was assigned. They
  now follow the same wall rule as the tasks: such an event answers "not found" like an
  unknown one and stays off every list, count and countdown. Nothing changes for people, and
  as with the tasks the state could not be reached in the app.