You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(appenroll): let the last phone go, at the box (#880)
The box's own page could remove phones down to the last one and then
stop: the row drew "add another before removing this one" where the
Remove button belongs. A household that lost its only phone, or wanted
to start clean, had no way back to an empty list from anywhere.
The refusal guards a real lockout, but only through one door. A phone
that empties the roster from the other side of the world leaves a box
nobody can administer, and nothing remote can mend it. Somebody at the
box is in a different position: the same page mints a fresh pairing
code, so the way back in is the button above the list.
Revoke now takes the presence of whoever is asking and refuses the last
owner over a session only. The decision stays in enrollment rather than
moving up to a screen; what is new is that the box is told which door
the request came through. That comes from the caller it named at
admission — LAN or kind "app" — never from a field a remote caller
could set. Demotion is unchanged at both doors: removing the last phone
leaves a list somebody at the box can fill again, and demoting it
leaves phones that can only look.
The device list follows. The last owner's row carries the same Remove,
and the warning lands at the press: a home down to one phone is told
nothing will see or change it until a phone is paired again with a code
from this page, and one with guests still paired is told those phones
will be left able to look and change nothing.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
A household can get back to no phones paired, from the box's own page. Until now the last owner could not be removed at all: the device list drew a sentence where the Remove button goes — add another before removing this one — so a home that lost its only phone, or wanted to start clean, had no way down to an empty list from anywhere.
6
+
7
+
The refusal was right about one door and wrong about the other. What it guards against is a phone emptying the roster from anywhere in the world: remove the last owner over a session and nobody can administer the box, and nothing done remotely can mend that. Standing at the box is a different position. Whoever reads that page is in the building, and the same page mints a fresh pairing code — the way back in is the button above the list. Refusing there protected nothing and stranded the household the rule was written for.
8
+
9
+
So `appenroll.Revoke` now takes the presence of whoever is asking, and refuses the last owner over a session only. The decision stays in enrollment rather than moving up to a screen; what is new is that the box is told which door the request came through. That fact comes from the caller the box named when it admitted the request — a LAN caller is minted as a local owner, an app session carries the kind `app` — and never from a field a remote caller could set. Removing the last owner through the app is still `E_LAST_OWNER_PROTECTED`, the same sentence and the same code.
10
+
11
+
Stepping the last owner down is still refused at both doors, the box's own page included. Removing the last phone leaves a list somebody at the box can fill again; demoting it leaves a list of phones that can only look, which is the lockout rather than a way out of it.
12
+
13
+
The box's device list follows. The last owner's row carries the Remove button every other row has, and the warning lands where it belongs — at the press, saying what is on the other side of it. A household down to one phone is told that nothing will see or change this home until a phone is paired again, with a code from this page. One with guests still paired is told those phones will be left able to look and change nothing. Both are what happens, which the old sentence was not: it described a rule the box no longer keeps.
0 commit comments