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. 웹 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을 보고한다면, 재푸시 이전에 이미지를 풀했거나 오래된 캐시 레이어를 사용 중인 것입니다(Watchtower 자동 업데이트에서 흔히 발생하는 문제). 해결 방법: 강제로 새로 풀하고 컨테이너를 재생성하세요:

```
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개 빌드와 같은 소수 수량이 내부적으로 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' 키 항목을 확인한 후 하나를 삭제하거나 주석 처리합니다. 그런 다음 php bin/console cache:clear를 실행하여 캐시를 지웁니다(Docker 환경에서는 컨테이너에 접속한 후 실행). 또는 공식 수정 사항이 릴리스될 때까지 버전 1.15로 다운그레이드하세요. 영구적인 해결을 위해 GitHub 이슈 #919를 추적하십시오.

Part-DB-server

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트