Question 1

Part-DB 2.9.1でユーザー編集を保存する際に「403 Forbidden」エラーが発生する場合の修正方法は？

Accepted Answer

このエラーは、config/permissions.yaml内のusersに対する'edit'操作が欠落しているために発生します。usersの下に次の内容を追加してください：operations:: edit: label: "perm.edit", alsoSet: ['read', 'edit_username', 'edit_infos'], apiTokenRole: ROLE_API_ADMIN。その後、影響を受けるユーザー/グループのpermissions_data JSONを更新し、usersセクションで"edit": trueを設定します。Part-DBを再起動してください。

Question 2

Part-DB API経由でmaster_picture_attachmentを設定する際の「The preview attachment must be a valid picture!」エラーの修正方法

Accepted Answer

これは、API Platformが`isPicture()`バリデーションに必要なデータを伴わずに添付ファイル参照をデシリアライズしたことが原因です。修正を含むリリースにPart-DBを更新し、ネストされたオブジェクトの代わりに添付ファイルのIRIを直接渡してください：

```bash
curl -X PATCH /api/parts/5 \
  -H "Content-Type: application/merge-patch+json" \
  -d '{"master_picture_attachment": "/api/attachments/14"}'
```

まず、添付ファイルが画像として認識されていることを確認してください：APIレスポンスに`"picture": true`が含まれ、外部URLが`.jpg`などの有効な画像を指している必要があります。

修正が含まれていない古いバージョンでは、次の回避策のいずれかを使用してください：
1. Web UIからマスター/プレビュー画像を設定する、または
2. バックアップを作成した後、データベースを直接更新する：

```sql
UPDATE parts SET id_preview_attachment = 14 WHERE id = 5;
```

Question 3

Dockerイメージをv2.20.2に更新したのに、なぜPart-DBはまだPHP 8.4.26を表示しているのですか（CVE-2026-109618 / CVE-2026-109619）？

Accepted Answer

`jbtronics/part-db1` の v2.20.2 タグは、パッチ適用済みの PHP 8.4.27(標準イメージと frankenphp イメージの両方)を含む形で再ビルド・再プッシュされ、重大な multipart/form-data の RCE 脆弱性である CVE-2026-109618 および CVE-2026-109619 が修正されました。コンテナがまだ PHP 8.4.26 を報告する場合、再プッシュ前にイメージを pull したか、古いキャッシュレイヤーを使用している可能性があります(Watchtower による自動更新でよく発生します)。修正方法: 強制的に新規 pull を行い、コンテナを再作成してください:

```
docker compose pull
docker compose up -d --force-recreate
```

Compose を使用しない場合: `docker pull jbtronics/part-db1:v2.20.2` を実行してからコンテナを再作成してください。`docker exec <container> php -v` でパッチが適用されているか確認してください — `PHP 8.4.27 (cli) (built: Oct 21 2026)` と表示される必要があります。KiCad/MCP 統合を使用しているインターネットに公開されたインスタンスでは、これは緊急の対応が必要です。

Question 4

小数のBOM数量を含むプロジェクトをビルドする際にPart-DBの「Add additional quantity」エラーを修正する方法

Accepted Answer

これは Part-DB 2.20.2 における浮動小数点の丸めバグです:0.26 l × 11 builds のような小数の数量は内部的に 2.8600000000000003 と計算されますが、withdraw フィールドは最大値を 2.86 に丸めるため、2.86 も 2.87 もバリデーションを通過しません。このバグは新しい Part-DB リリースで修正されています — 最新バージョンにアップデートしてください。影響を受けるバージョンでの回避策として、build フォームの 'Do not check quantities' チェックボックスを有効にして、バリデーションをバイパスしてください。

Question 5

アップグレード後にPart-DBのエラー500と'Provider with key digikey already registered'を修正する方法は？

Accepted Answer

このエラーは、Part-DB v1.16以上で部品を表示する際に、Digikeyプロバイダーの重複登録が原因で発生します。一時的な回避策として、ソースコードから重複した登録を削除します。Digikeyプロバイダーが定義されているファイル（通常はsrc/Providers/またはconfig/services内）を特定し、重複している'digikey'キーのエントリを見つけて、そのうちの1つを削除するかコメントアウトします。その後、php bin/console cache:clearを実行してキャッシュをクリアします（Dockerの場合は、コンテナ内でexecして実行します）。あるいは、公式修正がリリースされるまでバージョン1.15にダウングレードします。恒久的な解決策については、GitHub issue #919を追跡してください。

Part-DB-server

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト