> For the complete documentation index, see [llms.txt](https://visionstore.gitbook.io/visionstore-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://visionstore.gitbook.io/visionstore-docs/scripts/weaponhub/guides/admin-and-staff.md).

# Admin and staff

Admin commands, placing benches, job benches, fees and issued equipment.

## Who is an admin?

A player is an admin when **any** of these match (see [General settings](/visionstore-docs/scripts/weaponhub/configuration/general.md#admins)):

* The ace `vision_weaponhub.admin`:

  ```properties
  add_ace group.admin vision_weaponhub.admin allow
  ```
* One of `Config.Admin.groups` (`admin`, `god`, `superadmin` by default), as an ace group, a QBCore permission or an ESX group.

## Open the hub anywhere

Type **`/weaponhub`**. The hub opens where you stand, with **no job, item or fee rules**. Handy for testing a new weapon pack or fixing a player's gun.

## Place a workbench

{% stepper %}
{% step %}

### Copy an entry

Stand where players should use the bench and type **`/weaponhub_here`**. A ready-made entry is copied to your clipboard and printed in F8:

```lua
{
    id = 'bench_4821',
    label = 'Weapon Workshop',
    coords = vec3(x, y, z),         -- just in front of you
    size = vec3(1.6, 1.2, 1.6),
    rotation = 0.0,                 -- your heading
    distance = 2.0,
    jobs = nil,
    items = nil,
    price = nil,
    preview = vec4(x, y, z, h),     -- a display spot in clear air

    blip = false,
    prop = nil,
},
```

{% endstep %}

{% step %}

### Set the rules

Paste it into `Config.Locations` in `config/locations.lua` and fill in what you need: `label`, `jobs`, `items`, `price`, `blip`, `prop`. Every field is explained in [Workbenches](/visionstore-docs/scripts/weaponhub/configuration/workbenches.md).
{% endstep %}

{% step %}

### Restart

`restart vision_weaponhub`. Turn on `Config.Debug` to see the zone while you fine-tune it.
{% endstep %}
{% endstepper %}

## Job benches

Give police their own armory bench, or let only mechanics run a gunsmith:

```lua
jobs = { police = 0, sheriff = 0 },     -- any grade
jobs = { mechanic = 2 },                -- grade 2 and up
```

With ox\_target, players without the job don't even see the option. The server checks it again on every open and save.

## Issued equipment

If your armory script marks what it hands out with `policeArmory = true` in the item metadata, those guns and parts can only be changed by the jobs in `Config.IssuedEquipment`:

```lua
Config.IssuedEquipment = {
    key = 'policeArmory',
    jobs = { police = 0, sheriff = 0 },
}
```

* A civilian holding an issued gun can't open it in the hub.
* Issued parts keep their metadata on the weapon and get it back when removed (`Config.KeepPartMetadata = true`), so they can't be turned into personal parts.

Set `key = false` to turn this off. Using a different flag? Change `key` to the name your armory writes.

## Handing out parts

Attachments are normal ox\_inventory items. Sell them in a shop, add them to crafting, or put them in loot. The 22 extra items from `install/ox_inventory_items.lua` cover MK II special ammunition, MK II pistol slides, the rail cover, the sniper scope and three rare finishes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://visionstore.gitbook.io/visionstore-docs/scripts/weaponhub/guides/admin-and-staff.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
