@fluid-app/fluid-cli-member-site 0.1.29 → 0.1.30

package/README.md

@@ -38,20 +38,23 @@ which it is with `--as member` or `--as admin`, and a site of the other owner
 kind is refused before any request, with the login it needs. Without `--as`,
 the server decides, and a refusal names the login the site needs.
 
-`fluid login` signs in admins and reps. An admin who is also a rep of the same
-company builds both kinds of site after one normal `fluid login`: `--as admin`
-builds company sites with the admin session, and `--as member` builds the
-admin's own member sites with a rep session that the identity service narrows
-the same login to, with no second sign-in. The identity service issues that
-rep session only to a person who is a rep in the company. An admin who is not
-one gets "You are not a rep at <company>, so you cannot build a member site
-there. Use --as admin for company sites." before any member API request.
-
-Only a login made through the identity service can be narrowed. A legacy login,
-and a token set in `FLUID_TOKEN`, are sent as they are for `--as member` too,
-so an admin on a legacy login is still refused by the member API and builds
-company sites only. A member signs in to this command with the member's own
-token, set in `FLUID_TOKEN`.
+`fluid login` signs in admins and reps, and either login builds member sites.
+A rep's login writes to the member API as that rep. An admin who is also a rep
+of the same company builds both kinds of site after one normal `fluid login`:
+`--as admin` builds company sites, and `--as member` builds the admin's own
+member sites, acting as that person's own rep membership, with no second
+sign-in. On a company on the identity service the CLI narrows the login to a
+rep session; on the legacy sign-in the member API accepts the admin's login for
+that person's own rep membership.
+
+An admin who is not a rep of the company has no member sites there. On the
+identity service the CLI says "You are not a rep at <company>, so you cannot
+build a member site there. Use --as admin for company sites." before any
+request; on the legacy sign-in the member API refuses the login. A token set in
+`FLUID_TOKEN` is sent as it is: an admin's opaque admin token is refused by the
+member API, while an admin's legacy login JWT acts only for that person's own
+rep membership, as `fluid login` does. A member who is not a rep signs in to
+this command with the member's own token, set in `FLUID_TOKEN`.
 
 ## Commands
 
@@ -107,8 +110,9 @@ rileys-shop/
   page is `pages/index.liquid`.
 - `config/access.json` is the site's declaration of the viewer data it uses and
   the actions it takes as the viewer: `{ "uses": ["member.email", "orders: read"] }`.
-  A member site has it once it has a draft declaration, and a company site never
-  does. It is a draft until the site is published.
+  A site has it once it has a draft declaration, whoever owns the site: a company
+  site's is written with an admin login that may change themes. It is a draft
+  until the site is published.
 - `config/pages.json` holds the site's default `layout` and, for each page, its
   `slug`, `title`, `position`, `published`, `layout` and `menu` (the menu's
   slug). It holds no page content, which is in `pages/<slug>.liquid`. A page
@@ -173,8 +177,7 @@ What it sends, in this order:
 2. Each changed or new layout, section, snippet and asset, and `config/access.json`
    (`PUT files/:path`), in path order, so the declaration goes ahead of the
    layouts. A changed file carries its recorded `version`; a new one carries
-   `must_not_exist`. On a company site the push leaves `config/access.json`
-   alone and says so, as the server refuses the path.
+   `must_not_exist`. A company site's `config/access.json` is pushed the same way.
 3. Each new page (`POST pages`) with its file's content, then each changed page
    (`PATCH pages/:id`) with the changed row fields and the changed content, each
    with the page's `lock_version`.

package/dist/index.mjs

@@ -1791,10 +1791,6 @@ function isPlainFile(path) {
 	const kind = classifyPath(path).kind;
 	return kind === "layout" || kind === "section" || kind === "snippet" || kind === "asset" || kind === "access";
 }
-/** A company site takes no declaration and the server refuses the path, so a push leaves it alone. */
-function skipsAccess(binding, path) {
-	return binding.owner_kind === "company" && path === "config/access.json";
-}
 function isRecord(value) {
 	return typeof value === "object" && value !== null && !Array.isArray(value);
 }
@@ -2177,10 +2173,6 @@ function planPush(binding, tree) {
 	}
 	for (const [path, text] of [...tree.files].sort(([a], [b]) => a < b ? -1 : 1)) {
 		if (!isPlainFile(path)) continue;
-		if (skipsAccess(binding, path)) {
-			plan.notes.push(`${path} is not pushed: a company site takes no access declaration.`);
-			continue;
-		}
 		const bound = binding.files[path];
 		if (!changed(text, bound?.sha256)) continue;
 		if (path === "config/access.json") {
@@ -2212,7 +2204,6 @@ function planPush(binding, tree) {
 	}
 	for (const path of Object.keys(binding.files).sort()) {
 		if (!isPlainFile(path) || tree.files.has(path)) continue;
-		if (skipsAccess(binding, path)) continue;
 		const bound = binding.files[path];
 		if (bound.version === void 0) {
 			plan.refusals.push(noVersion(path));