This isn’t a valid solution, but it gets closer to one by
ensuring the token is loaded when the application boots. Then
I can add another step to load and parse the token’s policies.

The endpoint doesn’t actually support this 😳

This should have been part of dc98403.

It’s cut off by the edge of the viewport for now!

These unrelated tests were failing because they assumed that
the first 404 was stable.

Here’s another similar instance.

My placeholder test was incorrect.

The “greatest number of matched characters” part is still
forthcoming.

It’s too bad reduce is so unwieldy in Javascript… maybe this
would be better a for loop ☹️

This is written assuming #6017 is merged as-is. It’s trivial
to change the property name if needed!

This regex shows what’s permitted:
https://github.com/hashicorp/nomad/blob/5abbee5d396c0ce693cae570a6a8ac43aa640cdc/acl/policy.go#L38

…ui/respect-acl

The API change in #6017 returns JSON that contains the
expanded policy, including all capabilities implied
by a policy. So even if you set `policy="write"`, you
get back a list of capabilities that includes `submit-job`.
There’s therefore no reason to examine the returned policy.

These were only being used with hcl2json.

# Conflicts:
#	ui/app/routes/application.js
#	ui/mirage/scenarios/default.js
#	ui/package.json
#	ui/yarn.lock

…pect-acl

# Conflicts:
#	ui/mirage/scenarios/default.js
#	ui/package.json
#	ui/yarn.lock

Since the API expands a policy shorthand like “write” into
its constituent capabilities, examining the policy is
no longer needed.

I’m hesitant to add storage-clearing before every test.

Thanks to @johncowen for pointing out that this is on the
way to being deprecated: #5944 (comment)

emberjs/rfcs#554

This must have seemed/been necessary at some point but
doesn’t break anything when removed!