* fix: accept std "To" addrs in announcement tool

* fix: fix failing tests

Some code changes, some test changes.

* chore: remove obsolete files in k8s/

* chore: remove unused/OBE API signing key

* chore: lint

* chore: remove GITHUB_BACKUP_API_KEY setting

* docs: restore/rename the example secrets.yaml

…11549)

* feat: show rfc editor queue status on search result rows

* docs: commentary on prefetch states and tags for iesg agenda

…etf-tools#11597)

* feat: UUIDs as person identifiers

* feat: person uuid oidc claims and apis

* chore: ruff ruff

* fix: adjust how push is triggered

* fix: keep the mypy ignore on the person model import

Reformatting the import into a parenthesized block moved the ignore comment to
the closing paren. mypy reports the simple_history HistoricalPerson and
HistoricalEmail attribute errors against the 'from ... import (' line, so the
comment has to sit there to suppress them.

* refactor: register the anycase_uuid converter in the root URLconf

Registering it in ietf/utils/converters.py made importing that module a side
effect, and Django refuses to register a converter twice, so naming the
converter from a second URLconf was a latent error. Define it there, register it
once in ietf/urls.py before urlpatterns names it.

* fix: create a Person and its primary UUID atomically

A Person with no primary UUID cannot be named to any external system, so the
create and the assign_primary_uuid() that follows it have to succeed or fail
together. Covers all three production creation sites, including the draft
submission one, and wraps the surrounding aliases and nominee email so a
failure part way leaves nothing half-built.

* refactor: give each UUID batch endpoint a single response serializer

The resolved/unknown split needed a PolymorphicProxySerializer, which is an
annotation helper rather than a real serializer, so the endpoints hand-built
dicts and told consumers not to infer the outcome from which fields were
present. Use one entry serializer per endpoint instead, discriminated on status,
with the identifier fields nullable and always present, and actually serialize
responses through it so the schema cannot drift from what is returned.

Drops the ResolvedStatusEnum/UnknownStatusEnum overrides that existed only to
keep the two single-valued status enums apart - there is now one StatusEnum. The
entry fields are not read_only because read_only implies required=False, which
left a generated client treating even status as optional.

Also annotates retrieve with @extend_schema_view rather than overriding it just
to call super().

* refactor: serve the pk-to-UUID conversion from a plain APIView

Routing this lookup through a GenericViewSet forced the handler to be named
create, because that is what SimpleRouter maps POST to on a collection route.
Nothing is created: the view returned 200 while drf-spectacular inferred 201
from the action name, so the schema advertised a status code the endpoint never
sends and a generated client would treat the real response as unexpected.

An APIView.post() returns 200 with no annotation gymnastics. The viewset was
buying nothing else - no retrieve, no mixins, and an empty queryset. api_key
auth is unaffected, since HasApiKey just reads api_key_endpoint off the view.

The URL is unchanged. Its name loses the router's -list suffix, and the schema
test now checks the declared success codes so this cannot drift again.

* feat: carry both UUID claims in one OIDC scope

Splitting the current identifier and the superseded ones across two scopes was
finer-grained than any consumer needs - there is no case for granting one and
not the other, and the prior list is far too short for response size to matter.

Also corrects the scope description, which claimed the prior list included the
identifier in use now. It does not, and datatracker_uuid is where that lives.

* fix: check for exactly one primary UUID, not just one or more

The job logged that every Person has exactly one primary while only looking for
Persons with none. The partial unique constraint should make more than one
impossible, so finding one means the data is grossly inconsistent and worth
reporting - and ensure_primary_uuid() cannot repair that case, since it would be
picking a survivor arbitrarily, so it is reported and skipped rather than
silently 'fixed'. Same change in the base-test-data check.

* fix: let the UUID push enqueue use the default retry policy

Celery's default is three attempts over well under a second, which is cheap
enough on the request path that changed the UUID set and is the difference
between riding out a broker blip or failover and dropping the push on the floor.
The broker-error catch still keeps an outright outage from failing the
datatracker operation.

* chore: add dev API tokens for the person UUID endpoints

Neither endpoint had an APP_API_TOKENS entry in the container config, so every
call to them from a dev environment got a 403.

* test: build Person UUIDs with the factories and read them through the accessors

PersonFactory now makes its Person's primary UUID with PersonUUIDFactory instead
of calling assign_primary_uuid() itself, so all UUID handling in tests goes
through the factories. PersonFactory(primary_uuid=False) covers the
no-UUIDs-at-all case, which no production path can reach, replacing the tests
that created a Person and then deleted its UUID rows.

Tests now assert through Person.primary_uuid and Person.prior_uuids rather than
querying uuids directly, so the accessors are the example to copy. Direct
queries remain only where they are the point: the test proving the accessors
agree with the rows, and setup that deliberately builds inconsistent state.

Also drops the retry kwarg assertion that went with the old retry=False.

* fix: order prior_uuids deterministically

A merge stamps every UUID it moves with the same time, so ordering the prior list
on time alone left the order undefined in exactly the case where there is more
than one prior. Break ties on the UUID, which also makes the claim that
uuid_sets_for() matches this accessor true - it was already ordering on both.

* docs: correct why prior_uuids breaks ties on the uuid

The previous comment justified the tie-break by claiming a merge gives every
UUID it moves the same timestamp. It does not: merge_persons() moves them with a
queryset update that names only person and primary, and PersonUUID.time is a
per-row default with no auto_now, so each keeps its original timestamp.

The tie-break stands on narrower ground - it makes the order total instead of
leaving equal timestamps to the database, and matches the ordering uuid_sets_for()
already used - so only the comment changes.

* test: clear over-zealous concerns about API return values

---------

Co-authored-by: Robert Sparks <rjsparks@nostrum.com>

…up (ietf-tools#11529)

Bumps the npm group in /playwright with 1 update: [npm-check-updates](https://github.com/raineorshine/npm-check-updates).


Updates `npm-check-updates` from 23.0.1 to 23.0.2
- [Release notes](https://github.com/raineorshine/npm-check-updates/releases)
- [Changelog](https://github.com/raineorshine/npm-check-updates/blob/main/CHANGELOG.md)
- [Commits](raineorshine/npm-check-updates@v23.0.1...v23.0.2)

---
updated-dependencies:
- dependency-name: npm-check-updates
  dependency-version: 23.0.2
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: npm
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…s#11596)

* feat: add model for open RPC action holder entries

The RPC tool sends the action holders it is waiting on with every
publication queue push, and the datatracker discards them. Add somewhere
to keep them so an Area Director can be shown when the RPC needs a
decision from them.

The RPC tool owns these entries; this is a read-only capture held here so
the datatracker can query them efficiently. Only open entries are kept,
so readers do not need to filter. The admin registration is read-only for
the same reason: every push replaces the contents.

* feat: capture open RPC action holders from the queue push

The publication queue push already carries the action holders the RPC is
waiting on. Reconcile them against the open entry table on each push,
which is a full snapshot: entries the RPC completed or removed, and
entries for documents that have left the queue, are dropped.

Never associate an entry with the "(System)" person. The RPC tool sends
its own placeholder person when no real one was named, and that arrives
both with and without a body set - its edit path can change the body
without touching the person - so the person id alone has to be enough to
reject it.

* feat: show ADs the RPC decisions pending from them

Add a section to the AD document list for the actions the RPC is waiting
on that AD for. Each row links to the queue site final review page for
its document, which is where the request is spelled out - unless the RPC
has not assigned an RFC number yet, in which case there is no such page.

Who holds an action and since when is public. The request text itself is
shown only to the IESG, the Secretariat, the RPC, and whoever is being
asked for the decision.

* feat: count pending RPC decisions on the IESG dashboard

Add a table listing each AD the RPC is currently waiting on, above the
state count tables and linking to that AD's document list. Only ADs with
something pending get a row, and the table is absent when the RPC is
waiting on nobody.

It is kept out of the state count tables because it cannot honestly join
them: those show a 120-day trend, while the open entries the RPC pushes
are a snapshot with no history to bucket.

* feat: show open RPC action holders on the document page

Add the people the RPC is waiting on to the RFC Editor block, so the
document itself says who holds the decision and since when.

Only entries naming a person are listed. An action held by a body, or by
the RPC tool's own placeholder person, is already covered by the queue
status line in the same block.

* fix: only show rpc action holders on the current draft version

* fix: show action holder request on ad pages

* docs: correct comment gate rationale

* fix: add API resource for open RPC action holder entries

* docs: improve accuracy of comments

* fix: rename/redoc when to display comment method. Address other review nits

…ools#11621)

generate_idnits2_rfc_status() allocated a fixed 10000-element array
and indexed it by RFC number, so it raised IndexError for any RFC
above 10000. The task has been failing on every run since 2026-06-16,
and because ietf/doc/tasks.py computes the blob outside its try block,
the exception escapes before anything is written. The served file has
been frozen at 9998 characters since then (content-length 10154),
stale for all RFCs rather than only 5-digit ones.

This commit sizes the array from the highest rfc_number instead. The
most recent versions of idnits2 (through 2.17.1) will correctly
consume this larger array without modification.

It also stops the generator crashing on RFC rows it doesn't expect by
excluding RFCs with a null rfc_number (int(None) raises TypeError) and
falling back to 'U' for an unrecognised std_level_id (symbols[None]
raises KeyError). Document.std_level is nullable, and a single such
row would take down the whole task.

To allow existing idnits clients at version 2.17.1 and below to keep
operating, override RFC 16 to 'O'. This deliberately contradicts both
the datatracker and the RFC Editor, which record RFC 16 as updated
rather than obsoleted. idnits2 validates its download of this file by
matching the first 64 characters against a literal pattern asserting
'O' at position 16. The reason is lost, but it was likely the result
of manual curation at tools.ietf.org long ago. Without the override,
existing idnits2 clients discard the file as corrupt, fall back to
whatever stale copy they have, and silently perform no RFC status
checks at all. This is independent of the crash and predates it.

Note that the generator uses a floor of 6312. This is required because
the RFC 16, RFC 200 and RFC 6312 workarounds write those offsets
unconditionally, so the array must reach 6312 regardless of the data;
without the floor the generator raises IndexError for any dataset
whose highest RFC is below that. It also keeps output identical to the
previous behaviour, where the fixed 10000-element array always had
those offsets in range. Making the workaround writes conditional
instead would remove the need for the floor, but that was not done
here.

Verification:

- Against the production snapshot, positions 1..9993 and the first line
  are byte-identical to the pre-change algorithm; the blob extends from
  9999 to 10031. rfc10001='B', rfc10008='P', rfc10031='P' match their
  std_level_id values.
- idnits2's own download validation (grep -qsE against the first line)
  now passes, where it fails against the file production serves today.
- idnits2's lookup path resolves 5-digit statuses correctly against the
  generated file: rfc10001 -> Best Current Practice, rfc10031 ->
  Proposed Standard, rfc10032 -> past end of blob.
- ietf.doc.tests (122 tests) and ietf.doc.tests_tasks
  ietf.doc.tests_downref (15 tests) pass.

This commit produced primarily by Claude.

* chore: disable CryptPasswordHasher

* chore: adjust "invalid password" message

* feat: first pass attended-regs API (WIP)

* refactor: prefetchable Registration.attendance_type

* feat: add ticket type methods + refactoring

 * rename `Registration.attendance_type` to `plenary_attendance_type`
 * add `plenary_ticket_type`
 * refactor to ensure consistency, reduce queries, handle bulk requests

* refactor: adjust api to match changes

* test: meeting RegistrationTests

* fix: refactor to avoid mypy limitations

* test: Registration onsite() and remote() filters

* fix: lint + add some docstrings

* refactor: adjust api token endpoint name

* perf: bulk annotation in proceedings_attendees

* test: start test coverage of new API

* test: flesh out the tests

* fix: failing test

* fix: distinct() in onsite_or_remote()

* test: fix/update tests

* refactor: limit sessions to `interim` meetings

* refactor: only fetch ietf_group if needed

* refactor: filter in db, not python

* refactor: limit meeting queries for interim views

Presumably a meeting will be no longer be pending or awaiting
announcement by a year after its date.

* chore: adjust lookback / comments

* style: ruff ruff

* perf: cap per-client concurrency on /person/ and /api/v1/

Keyed on the Cloudflare client address, with an empty key for every other
path so only these two prefixes are limited.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* perf: query the two authorship tables separately in Person.rfcs()

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* perf: avoid table scans and per-alias queries in lookup_persons

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* perf: assemble the profile page's data in the view

Gathers the RFC publication dates, reference counts and replaced-draft set for
every listed person in one query each, rather than a query per table cell, and
evaluates each per-person list once instead of on every template reference.

The expired Internet-Drafts heading now counts the drafts it lists; it counted
the replaced ones the list omits. Roles with the same name sort by group
acronym instead of by whatever order the query returned.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* perf: cache each rendered profile section

A repeat view of a profile, including the revalidation behind a conditional
request, now costs neither the queries nor the render. Sections are keyed on
person and date rather than position on the page, so the per-section element
ids move from a loop counter to the person's id.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test: guard the profile page's query count and section cache

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* revert: perf: cap per-client concurrency on /person/ and /api/v1/

This reverts commit fed51f0.

* refactor: make the profile section cache lifetime a setting

PERSON_PROFILE_CACHE_SECONDS, overridable from the environment in the k8s
deployment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix: stop dating the profile page's empty-section messages

The dates claimed a precision the page does not have: sections are cached
independently, so the data behind two of them can differ by a cache lifetime
while both printed the same date. Without them nothing in a section depends on
when it was rendered, so the cache key no longer needs the date either.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…etf-tools#11241)

* Fix: Point to pending interims in meetings list (ietf-tools#11069)

* test: improve coverage

---------

Co-authored-by: Robert Sparks <rjsparks@nostrum.com>

* refactor: date-limit for has_pending_interim()

* style: clean up imports in meeting/views.py

* refactor: use common lookback time everywhere

* style: ruff ruff

* test: fix failing tests

Put test meetings in the future instead of arbitrary old date