Test Project Settings & Build Management in AXQA

Once a project is created, its settings define how it behaves day to day — who can access it, what stage it’s in, and which build/version is currently active. Keeping project settings accurate helps the whole team stay aligned.

Why it matters

• Clarity: everyone knows the current status and scope of the project.
• Control: you decide who can access or modify the workspace.
• Traceability: linking the correct build/version keeps executions meaningful.

When to use it

• You need to update the project status (e.g., move from demo to active).
• You want to change visibility (Private ↔ Team ↔ Public).
• You’re starting work on a new build/version.
• You need to adjust description, dates, or team members.

Core concepts

• Project Status – demo / active / closed (lifecycle stage).
• Project Type – controls visibility scope.
• Current Build – the active ProjectBuild linked to executions.
• ProjectMembership – connects users to the project as team members.

How it works

1. You open the Project Settings page.
2. AXQA loads the current project data (name, description, type, status, build).
3. You modify the fields you need.
4. On save, the system validates changes (e.g., date consistency).
5. If the build/version is updated, AXQA may create or switch the current build reference.
6. Changes are applied immediately across test cases, plans, and dashboards tied to the project.

How to use it

Step 1: Open Project Settings

Go to Projects → Select your project → Edit / Settings.

Step 2: Update general information

You can modify:
Project Name
Description
Start / End Dates

Step 3: Adjust visibility

Change the Project Type if needed:

Private – limited accessTeam – access controlled by membershipsPublic – visible to broader users (execution rules may still apply)

Step 4: Update status

Switch between:

Demo – initial/testing phaseActive – currently in useClosed – no longer active (kept for history)

Step 5: Manage current build

If a new version is released, update or create a new build entry and set it as current build. This ensures new executions are clearly tied to the right release.

Step 6: Save changes

Click Save. Updates take effect immediately.

Best practices

• Keep status accurate — dashboards and reports rely on it.
• Don’t overuse “Public” unless visibility is intentional.
• Create a new build entry instead of editing historical build data.
• Review team memberships when changing project type.

Common mistakes

❌ Changing project type without reviewing permissions
✔ Double-check memberships and execution rules after modifying visibility.

❌ Overwriting old build information
✔ Create a new build and set it as current instead of editing history.

❌ Closing a project while it’s still actively used
✔ Confirm no ongoing test plans depend on it before marking as closed.

Security & permissions

• Only authorized users (owner / staff / permitted members) can edit project settings.
• Form inputs are validated and sanitized to reduce injection or malformed data risks.
• Execution permissions are separate from visibility and handled by dedicated access decorators.

Related documentation

• Creating a Project
• Project Visibility & Access Control
• Project Builds