83 lines
4.5 KiB
Markdown
83 lines
4.5 KiB
Markdown
# Submitting components as Altium 365 Part Requests (web browser)
|
|
|
|
When the central library is a managed **Altium 365 Workspace** and the operator is **not an
|
|
admin**, the skill's end task can be to submit each finished component as a **Part Request**
|
|
through the Workspace's web UI, driven by browser automation (Claude-in-Chrome). A librarian
|
|
then approves each request into the managed library. This runs in the operator's **own Chrome,
|
|
using their existing Altium 365 login**, so it needs **no API token and no admin rights** — it
|
|
just does what the engineer would do by hand, for every component in the run.
|
|
|
|
This is the browser alternative to the headless API push (`altium365_push.py`, if a token is
|
|
ever available) and to the Gitea push. Use whichever matches how the org consumes the library.
|
|
|
|
## Prerequisites (each run)
|
|
|
|
- **Chrome open** with the Claude-in-Chrome extension enabled, and **site permission granted**
|
|
for the Workspace domain (e.g. `vecmocon.altium365.com`).
|
|
- **Signed in** to the Altium 365 Workspace as any member with rights to create Part Requests.
|
|
- **The component files on the LOCAL machine** — the browser uploads attachments from local
|
|
disk, so each component's `.SchLib` (with parameters written), `.PcbLib`, and datasheet must
|
|
exist on the operator's computer. If the skill produced them in the cloud, commit them to the
|
|
device first (device bridge) into a known folder, and put those local paths in the manifest.
|
|
- **The manifest** of components to submit this run (below).
|
|
- **Decisions the operator confirms once**: the default **Assign to** (the librarian/group), the
|
|
**Component Type** mapping for each typeid, and an optional **Required By** date.
|
|
|
|
## Per-component field mapping (the Part Request form)
|
|
|
|
| Form field | Value (from the skill's per-part data) |
|
|
|---|---|
|
|
| Manufacturer | `Manufacturer` param (e.g. `Taiyo Yuden`) |
|
|
| Manufacturer Part Numbers | `Manufacturer Part` param (the MPN) |
|
|
| Description | `Description` param (SOP format, e.g. `CHIP_CAP_1uF_6.3v_±10%_0402_x5r`) |
|
|
| Component Type | the typeid mapped to the Workspace's matching component type (confirm once per typeid) |
|
|
| State | leave `Opened: New` |
|
|
| Required By Date | optional org default |
|
|
| Assign to | the configured librarian / group |
|
|
| Parameters → Add | every parameter from the full set (name + value) |
|
|
| Attachments | the `.SchLib`, `.PcbLib`, and datasheet files |
|
|
| Parts List → Add | optional: add the MPN as a part choice so the librarian's mapping is pre-seeded |
|
|
|
|
## The manifest
|
|
|
|
The skill writes one `part_requests.json` per run listing every component it processed, so the
|
|
browser step can loop without re-deriving anything:
|
|
|
|
```json
|
|
{"requests":[
|
|
{"manufacturer":"Taiyo Yuden","mpn":"JMK105BJ105KV-F",
|
|
"description":"CHIP_CAP_1uF_6.3v_±10%_0402_x5r","component_type":"Capacitor",
|
|
"parameters":{"Value":"1u","Voltage(V)":"6.3","Tolerance":"±10%","...":"..."},
|
|
"files":["C:\\...\\JMK105BJ105KV-F.SchLib","C:\\...\\<footprint>.PcbLib","C:\\...\\<mpn>.pdf"],
|
|
"assignee":"<librarian>","required_by":""}
|
|
]}
|
|
```
|
|
|
|
Build it from each component's `params.json` plus the local file paths (after committing files
|
|
to the device).
|
|
|
|
## Browser procedure (looped per component)
|
|
|
|
Start the browser session with `tabs_context_mcp`, then for each entry in the manifest:
|
|
|
|
1. Navigate to **Library → Part Requests → new request**.
|
|
2. Fill **Manufacturer**, **Manufacturer Part Numbers**, **Description**.
|
|
3. Choose **Component Type**; set **Assign to**; optional **Required By Date**. Leave State as
|
|
`Opened: New`.
|
|
4. **Parameters → Add**: add each parameter name + value.
|
|
5. **Attachments** (Choose file / drop): upload the `.SchLib`, `.PcbLib`, and datasheet.
|
|
6. Review, then **Save**. Record the auto-assigned **Request Id**.
|
|
7. Move to the next entry.
|
|
|
|
## Safety and auditing
|
|
|
|
- On the **first component of a run**, fill everything and **stop at Save** for the operator to
|
|
eyeball the mapping. Once they confirm it looks right, Save it and loop the rest unattended.
|
|
- **Log every submitted Request Id** (and any component that failed) so the run is auditable and
|
|
re-runnable — never silently skip a component.
|
|
- Browser automation follows the live UI. If a field, dropdown option, or a popup doesn't match
|
|
what's expected, **pause and ask** rather than guessing — a wrong Component Type or a
|
|
half-filled request is worse than one clarifying question.
|
|
- Don't trigger native file-dialog blocking: use the extension's file-upload path for
|
|
attachments, not an OS dialog.
|