Question 1

Why does Snipe-IT API hardware pagination skip or miss assets when using limit and offset?

Accepted Answer

Snipe-IT defaults the `/api/v1/hardware` index sorting to `created_at`, which is not unique. When many assets share the same creation timestamp (e.g., batch imports), offset-based pages can overlap or silently skip records. Fix: add an explicit unique sort to every paginated request, e.g. `GET /api/v1/hardware?limit=200&offset=0&sort=id&order=asc`, then continue incrementing `offset` per page. This returns the complete inventory consistently. Also verify the issue on the latest Snipe-IT version and confirm it is not an FMCS company-scoping restriction before assuming a permissions bug.

Question 2

Why can't I uncheck 'Create new Snipe-IT assets' checkbox on a sync adapter in Snipe-IT?

Accepted Answer

This is a known bug in Snipe-IT v8.8.3 (affects sync adapters like Microsoft Intune). In `app/SyncAdapters/SyncAdapter.php` (line ~907), the code uses `$request->boolean($slug.'_create_snipeit_assets_on_pull', true)` — since an unchecked HTML checkbox is not submitted, the missing field falls back to the `true` default and always saves `"1"`. Workaround: update the database directly:

```sql
UPDATE sync_adapter_instances
SET config = JSON_SET(config, '$.create_snipeit_assets_on_pull', '0')
WHERE slug = '<your-adapter-slug>';
```

Permanent fix: remove the `true` default in `$request->boolean(...)` or add a hidden `0` input in the form so the value is always submitted.

Question 3

Why does Snipe-IT Intune sync (snipeit:pull-inventory) run forever and never finish?

Accepted Answer

This affects Intune tenants with more than ~999 managed devices and is caused by a pagination bug in app/SyncAdapters/Intune/IntuneClient.php (managedDevices(), ~line 80). After the first Graph API page, an empty $query array is still passed to get(). Laravel forwards it as Guzzle's query option, and Guzzle replaces the request URI's query string even with an empty array — stripping the $skiptoken from Graph's @odata.nextLink cursor. Graph then serves page 1 again indefinitely, so the sync loops on the same devices and never completes. Fix: patch the line so $query is only passed when non-empty:

$response = ($query === [] ? $this->request()->get($url) : $this->request()->get($url, $query))->throw()->json();

Verify the fix with php artisan snipeit:pull-inventory <slug> --dry-run --limit=1500 — it should return 1,500 distinct device IDs instead of being capped at the first page (~999). A full pull should then finish (e.g., ~6,200 devices in about an hour).

```php
$response = ($query === [] ? $this->request()->get($url) : $this->request()->get($url, $query))->throw()->json();
```

Verify the fix with `php artisan snipeit:pull-inventory <slug> --dry-run --limit=1500` — it should return 1,500 distinct device IDs instead of being capped at the first page (~999). A full pull should then finish (e.g., ~6,200 devices in about an hour).

Question 4

How do I fix Snipe-IT LDAP sync not disabling Active Directory users when Active Flag is blank?

Accepted Answer

In Snipe-IT v8.8.0, the new LDAP wizard can save a blank Active Flag as an empty string (`''`) instead of `NULL`. `LdapSync` only requests `userAccountControl` when the value is `null`, so AD-disabled users remain active. Immediate workaround: open the legacy LDAP settings form, leave Active Flag blank, save it, then run `php artisan snipeit:ldap-sync`. The legacy form converts the empty string to `NULL`. Verify with: `php artisan tinker --execute="var_dump(Setting::getSettings()->ldap_active_flag);"` It should output `NULL`. Permanent code fix: in `app/Console/Commands/LdapSync.php`, replace `is_null($ldap_map['activated'])` with `blank($ldap_map['activated'])` in the `userAccountControl` attribute request check, or make `app/Livewire/LdapSettings.php` persist blank optional mappings as `null`.

Question 5

How to fix empty Snipe-IT tables and "string literal contains an unescaped line break" with German de-DE locale in v8.8.0?

Accepted Answer

This is a v8.8.0 bug caused by a de-DE translation string containing a raw line break that breaks an inline JavaScript string, preventing bootstrap-table from initializing. Immediate workaround: change the affected user's language to English, or set `APP_LOCALE=en` in `.env` and restart the container. Permanent fix: upgrade to a Snipe-IT release newer than v8.8.0 containing commit `6525787ba523ea9655ce8f1dfe3310e4faaa63ee`. For Docker, run `docker compose pull && docker compose up -d`, then hard-refresh the browser. Existing asset and license data are not lost.

snipe-it

Overview

README Preview

FAQ (5)

同类型项目

vscode

FreeDomain

stable-diffusion-webui

paperclip