Wave 1: permissions roles, account-backed SOP team, critical constraints, password reset, BIM flag
Acts on the site comments from 8/3 plus the follow-ups. Foundation work first — four of the comments all needed the project team to resolve to real user accounts. Permissions vs project role (new) - User.role is now the PERMISSIONS role: admin | project_admin | project_user. project_admin may delete work packages, change a SOP after it is complete, and delete a project; project_user may not (archiving a WP is still open to them). Enforced by require_project_admin() server-side; the UI only hides dead ends. - New User.project_role holds the person's JOB FUNCTION on the project. It grants nothing — it feeds the SOP team pickers and notification routing. - Admin console shows both columns and explains the difference. Migration rewrites the legacy role 'user' to 'project_user'. - Deleting a project was previously open to any member and unaudited; it now needs project_admin and writes an audit event. ProjectData.remove no longer drops the project from the local cache when the server refuses. SOP project team from user accounts - PM/APM/CM/QM and additional team members are pickers over the project's members, storing the account id next to the display name. A name from an older SOP with no matching account is kept and flagged rather than dropped. - The WP Creator lists the SOP team first in the Owner picker, and a new package defaults to whoever is creating it. Critical constraints - SOP constraints carry a Critical flag; buildConstraints() now copies the whole definition through to the package (it previously reduced them to names, losing description too), and critical rows are marked in the WP form. The email on reopen-after-release is wave 3. Password reset by email - login.html gains Forgot password and a set-a-new-password view, offered only when the server reports email is actually configured. - Single-use signed token (AUTH_RESET_MINUTES, default 60) bound to token_version, sent immediately rather than through the notifications outbox so a reset link is never persisted. Identical response for unknown accounts; per-account send cooldown; a completed reset clears any login lockout. - Session and reset tokens are no longer interchangeable. BIM kill-switch - New admin Features card with bim_enabled, OFF by default. The SOP creator hides the BIM section and the Creator treats every package as install-only while it is off; a SOP that already has BIM keeps its data untouched. Verified with two throwaway-database test scripts: 44 checks on the permissions matrix and token handling, 22 on the reset flow end-to-end against a local SMTP sink (real message captured, link extracted and used). Front-end files parse-checked in headless Chrome. Not yet exercised in a browser against a real login. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -33,9 +33,19 @@ DEFAULTS = {
|
||||
"from_addr": "",
|
||||
"from_name": "Work Package Suite",
|
||||
"app_base_url": "", # e.g. https://wp.controls.dev — used to build email links
|
||||
# Feature flags (admin console). BIM/VDC is off until it's ready for the field:
|
||||
# with it off, the SOP creator hides the BIM section entirely and every SOP is
|
||||
# install-only, so no project can be put on the BIM path by accident.
|
||||
"bim_enabled": False,
|
||||
}
|
||||
|
||||
|
||||
# Settings the app needs before anyone is signed in, or that carry no secrets and
|
||||
# are safe for any authenticated user to read (feature flags + whether
|
||||
# self-service password reset can work at all).
|
||||
PUBLIC_KEYS = ("bim_enabled",)
|
||||
|
||||
|
||||
def get_settings(db: Session) -> dict:
|
||||
row = db.get(models.AppSetting, SETTINGS_KEY)
|
||||
s = dict(DEFAULTS)
|
||||
@@ -65,6 +75,16 @@ def public_settings(db: Session) -> dict:
|
||||
return s
|
||||
|
||||
|
||||
def app_flags(db: Session) -> dict:
|
||||
"""Feature flags for any signed-in user (no secrets, no SMTP detail).
|
||||
`password_reset_enabled` tells the login page whether a self-service reset can
|
||||
actually deliver mail — there's no point offering the link otherwise."""
|
||||
s = get_settings(db)
|
||||
out = {k: s.get(k) for k in PUBLIC_KEYS}
|
||||
out["password_reset_enabled"] = bool(s.get("email_enabled")) and smtp_ready(s)
|
||||
return out
|
||||
|
||||
|
||||
def smtp_ready(s: dict) -> bool:
|
||||
return bool(s.get("smtp_host") and s.get("from_addr"))
|
||||
|
||||
@@ -91,6 +111,22 @@ def send_email(s: dict, to_addr: str, subject: str, body: str) -> None:
|
||||
srv.send_message(msg)
|
||||
|
||||
|
||||
def send_now(db: Session, to_addr: str, subject: str, body: str) -> bool:
|
||||
"""Send one email immediately, outside the outbox. Used for password resets —
|
||||
a reset link must never sit in a queue, and it must not be persisted in the
|
||||
notifications table where an admin could read it and take over the account.
|
||||
Returns True if it went out."""
|
||||
s = get_settings(db)
|
||||
if not (s.get("email_enabled") and smtp_ready(s) and to_addr):
|
||||
return False
|
||||
try:
|
||||
send_email(s, to_addr, subject, body)
|
||||
return True
|
||||
except Exception as e: # noqa: BLE001 — never surface SMTP detail to the caller
|
||||
log.warning("password-reset email to %s failed: %s", to_addr, e)
|
||||
return False
|
||||
|
||||
|
||||
def enqueue(db: Session, *, user: "models.User", kind: str, subject: str, body: str,
|
||||
link: str = "", wp_id: Optional[str] = None, project_id: Optional[str] = None) -> "models.Notification":
|
||||
"""Record a notification. Marked 'pending' only if email is enabled + SMTP ready +
|
||||
|
||||
Reference in New Issue
Block a user