Site view¶

The /hub/view/<space>/<site>/ page and its sections. The API calls behind the actions are in 12-hub-api.

Site view¶

Routes and access¶

/hub/view/<space>/<site>/ renders hub/view.html for any logged-in user. The page shows the Overview section read-only to users who are not Site administrators; the Access, Configuration, Operations, and Analytics sections render only for Site administrators (site.access_management.is_current_user_admin). The four fragment endpoints (details/, sharing/, settings/, actions/) enforce the same rule server-side and raise an unauthorized error otherwise.

Header and summary cards¶

The hero shows the Site path with badges: type (Public/Private), status (Active/Archived), and the current user's role (Administrator/Viewer). Summary cards show the primary URL, the admin file-browser URL (Site administrators of enabled Sites only), the owner, the creation date, storage used versus reserved, and the retention review date. Three message banner slots (status, quota, retention) sit above the hero; the refresher fills them.

Sections¶

A "Sections" side navigation switches tab panels with $.wizard() (wizard.js) and mirrors the choice in the URL hash. The sections are: Overview (URLs, ownership, lifecycle, core metadata), Access (sharing), Configuration (security, headers, applications, resources), Operations (status, conditions, logs), and Analytics (only when the analytics integration is active).

Overview section¶

hub/view-tab-details.html lists the URLs (site URL; and for Site administrators of enabled Sites: admin file browser, OpenAPI page, ecBox WebDAV, and S3 interface, each with a copy button) and in-place editable fields. inplace.js PATCHes each field to the Hub API (/hub/api/v2/sites/<space>/<site>/…):

When the notification provider is active (context flag requests_available, hub/.../server.py), two request modals appear: Request publishing (enabled private Sites, non-administrators; posts a comment to requests/publish/) and Request additional storage (when the quota is at site.storage_max_quota; posts quota + comment to requests/storage/). The retention text quotes the configured jobs.retention_expired_archive_after_days and jobs.retention_expired_delete_after_days values (15).

Configuration section¶

hub/view-tab-settings.html groups the Site settings; each control calls the Hub API through inplace.js or a modal (hub/.../static/js/modal-utils.js):

• Master token: show, copy, and regenerate (POST …/token/).
• HTTP access tokens: create (POST …/access-tokens/ with permission r/rw, identifier, and expiry), history table with per-token revoke and JSON export (GET …/access-tokens/history/), and revoke by token (DELETE …/access-tokens/). Token semantics: 10-security.
• Signed URLs and session URLs, rendered only for private Sites: the signed-URL form takes permission, duration, and the full target URL; the session-URL form takes a required identifier, permission, duration, and an optional path scope (POST …/signed-urls/, POST …/session-urls/).
• Error handling (custom error pages), search-engine indexing (robots headers), CORS (extra domains picker), and no-cache headers (file extensions).
• Built-in applications: enable/disable through the application picker ($.OnDemandApplicationsLoad).
• Custom application: image, extra environment, proxy type (proxy/fastcgi), and context root (07-custom-applications).
• Monitoring and resource limits: platform administrators only.

Access section¶

hub/view-tab-share.html edits the administrator user/group lists and, for private Sites only, the view-only access user/group lists. The pickers load candidates from /hub/api/v2/users/?q= and /hub/api/v2/groups/?q=. The sharing model is in 03-domain-model.

Operations section¶

hub/view-tab-system.html shows, for an enabled Site, four cards — Overall, Site Status (hub/conditions.html), Nginx (the proxy health body), and Storage (used quota with a bar) — and a logs console: choose an application and a line count, and $.getLogs() requests GET …/logs/?name=<application>&limit=<n>.

Site Status card¶

site_status_panel(site_status, site) (hub/.../app/hub/site_status.py, a Jinja global) builds the data of the card from the SiteStatus. The template shows only this data.

• The card shows the time of the last pod condition change in UTC, in a <time> element, and the time since then, for example Not ready since 2026-01-01 10:00:00 UTC (5 minutes ago). When the condition has no time, it shows the pod start time. An empty or wrong time, or a time in the future, shows no duration and does not cause an error (date_utils.get_elapsed_time, which compares with the UTC time).
• Each container entry shows the application name, a short label, and one sentence of advice. classify_container (hub/.../app/hub/custom_application.py) uses the same rules as the Settings tab status line. The site-custom container gets the custom application advice. The raw reason and message stay visible and are escaped.
• For Site administrators, each entry of a container that has logs has a Load logs link. It selects the container in the logs console and loads the logs. The card shows Restart now (POST …/restart/) in the problem state, or when a container is NotReady.
• The Need help? text shows only in the starting and problem states. The sentence about port 8000 shows only when the Site has a custom image.
• The badge container has role="status" and aria-live="polite", because the refresher replaces the card. The hidden #lastTransitionTime element keeps the raw condition time for the refresher.

Actions menu¶

hub/.../app/hub/actions.py builds the hero Actions menu as action objects (URL, title, icon, HTTP method, confirmation message) rendered by hub/view-actions.html; each entry confirms with window.confirm before it calls the Hub API.

Force Upgrade is available even when no new application version exists; see 08 — Site actions.

Content refresher¶

For Site administrators only, $.refreshContent() (hub/.../static/js/site-view-content-refresher.js) keeps the page live:

• It polls GET …/status/ (JSON) every 15 seconds and pauses while the browser tab is hidden. A failed check shows a "perhaps the site is restarting" banner.
• It updates the hero status badge (Active/Archived) and the top banner.
• When status, enabled state, or the last condition transition changes, it re-fetches and replaces the details, settings, sharing, actions, and conditions fragments. It requests status/ with accept: text/html to re-render hub/conditions.html.
• It keeps the Container select of the logs console current. $.refreshLogContainers() requests GET /hub/view/<space>/<site>/log-containers/ (administrators only), which renders hub/system-log-containers.html, and replaces the options of #site-applications. The selected option stays selected when it still exists. This runs after each successful save (inplace:saved) and when the status changes, so a custom application that the user adds or removes shows without a page reload. The list comes from the Site spec, not from the running pod.
• It loads GET …/health/ at startup and after changes. The health payload updates the health cards, the storage bar and badges (Moderate at ≥50%, Warning at ≥80%, Critical at ≥90%), the used-storage quota badge, the storage summary card, and the retention-expired banner. A failed health request marks the cards Unknown.

Analytics section¶

hub/view-tab-analytics.html offers week and month selectors; $.getWeeklyReport / $.getMonthlyReport request …/analytics/weekly/ and …/analytics/monthly/ and render the report HTML. The section and its reports are unavailable for archived Sites, and the whole section needs the analytics integration (17-integrations).

Per-Site API specification¶

/hub/spec/<space>/<site>/ embeds Swagger UI. The paired …/swagger.json endpoint renders the site-api-spec.yaml template with the Site values, domain, and branding data, and caches the result in Redis (hub/views.py:_load_site_open_api_template). Site administrators only.