Plans and feature access

Your plan determines which tools and workspaces are available. A namespace
is an isolated workspace for a project or team. A module is a set of tools,
such as mocking or testing, that an administrator can activate for a user.
This page explains how modules and workspace roles work together.

Modules

Mockarty bundles several toolsets you can mix and match per user:

Note about AI assistance. The AI chat, the internal agent
network and the local MCP server are part of the base product —
every customer gets them. Sub-agents are bound to the modules
above: the fuzzer agent only joins a task when the user has the
Fuzzing module activated, the perf_tester when API Tester is
activated, and so on. Tools the LLM can see in chat are filtered
by the user’s modules so the assistant never offers an action it
can’t actually take.

For modules with seats, the administrator grants access to individual users.
The grant follows the user across their namespaces; their namespace role still
controls what they can do in each one. Separate modules may require separate
grants. External A2A is enabled for the installation as a whole.

Transition windows after a module split. When a module is carved out of an
existing key, the older key keeps opening it for a transition period, so an
upgrade never removes a module someone is already using. The current transition
window covers Processing & Communications, which the Test Case
Management key still satisfies. Content created during the window stays
readable afterwards; the new key is what editing and running require. An
administrator can watch how many licences still depend on the window — and how
to close it — from the MOCKARTY_PROCESSING_TCM_FALLBACK section of
Administration.

Roles in a workspace

Every team member belongs to one or more namespaces with a role in each:

• Owner — full control over the workspace and its resources.
• Member — can create and edit resources where their module grants allow it.
• Viewer — read-only.

Roles say what kind of changes a user can make in the workspace.
Module activations say what features they have access to at all.

The two work together. A user with the Testing module and the Viewer role can
read test plans they are allowed to see, but cannot edit them or start new runs.
A Member without the Fuzzing module cannot start fuzz runs. System roles such
as Admin, User, Auditor, and Support are separate from namespace roles; see
Administration for their permissions.

What teammates see in a shared workspace

When a module is active in a namespace, other members may be able to see
existing content from that module in read-only mode. They still need the
right namespace role and any resource-level sharing permission. Creating,
editing, and running work requires a personal grant for the module.

For example, a tester can run a plan and share its report with a teammate.
The teammate may read the report when their workspace and sharing permissions
allow it, but needs a Testing grant and a role with write access to start a
new run. Collection sharing settings apply separately; see
Web UI Guide for those controls.

What happens without a module

Without a personal grant for a module, a user can still sign in and read
content their role and sharing permissions allow. Pages for modules that are
not active in any of their namespaces may be hidden. A direct API request to
create, edit, or run work without the required grant is refused; ask an
administrator to activate the module for your user.

Trial

On first setup, Mockarty provides a 7-day trial. Each module with per-user
seats has three trial seats, so a small team can try the tools. An
administrator assigns those seats to users. After the trial, the administrator
loads a commercial license and grants the included modules to users.

Activating users

Activation is done by a system administrator from
Admin → Users → Edit user. The “Licensed features” section
lists the modules currently included in your tariff plan with the
number of seats remaining. Tick the modules you want to grant the
user, click Save. Unticking a module releases the seat back to the
pool.

Need more seats than your plan allows? The administrator panel
will show “no free seats” next to the corresponding module — buy
more or release a seat by deactivating an inactive teammate.

Usage limits and the usage meter

Some subscription plans cap usage metrics — for example the number
of mocks, or how many fuzzing and load-test runs can be started per
day. When your installation runs on such a plan, the
Admin → Licenses tab shows a usage meter: every capped metric
with its current usage, the plan limit, and a progress bar.

• Crossing 80% of a cap turns the meter amber and sends a
  “Plan limit approaching” notification to administrators (once per
  day, not per request).
• Reaching the cap blocks further creation of that resource with a
  clear “subscription limit reached” error; everything already
  created keeps working, and reading data is never blocked.
• Deleting resources (for stock caps like mocks) frees capacity
  immediately; daily run counters reset at midnight UTC.

Plans without caps — including standard on-premises licenses — show
no meter: nothing is limited.

Upgrading your plan

To add modules or seats to your plan, contact your account manager
or open the upgrade page from the license panel. Once a new
license is loaded by the administrator, the new modules become
available immediately — there is no need to restart anything.