ab696a910b267092e2bdf59dfd79e261dc06fcb2
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  awkawbandClaude Sonnet 5
|
fb670cbb08 |
Rename the crate from invoiceninjars to invoiceninja-sdk
The package name has never matched the repository it lives in (gitea.awkawb.cloud/awkawb/invoiceninja-sdk, mirrored to github.com/awkawb1/invoiceninja-sdk) — both pointed at `invoiceninja-sdk` while `Cargo.toml` declared `invoiceninjars`. Lines everything up on the name the repo has always used. Cargo derives the crate's Rust identifier from the package name by lowercasing hyphens to underscores, so every `use invoiceninjars::...` becomes `use invoiceninja_sdk::...` — in doctests across `src/`, the four examples, all four integration test files, and `README.md`. `Cargo.lock`'s own self-entry picked up the new name on the next `cargo check`, which is also when the rename gets its real check: every doctest and every test file has to resolve the new path to compile at all, not just the ones a grep happens to catch. `flake.nix`'s `pname` and description follow, so `nix build` produces `invoiceninja-sdk-0.1.0.drv` rather than a name that no longer matches anything. `GOALS.md`'s two mentions — the hypothetical CLI's name and the `cargo install` example — follow too, for the same reason. Verified clean on both the dev toolchain and the 1.88 MSRV shell: full test suite (209 tests), clippy, fmt, and `nix build`/`nix flake check`. Not yet published to crates.io (checked: the name 404s there), so this lands before the old name was ever claimed — no one's `Cargo.toml` breaks today, but it's recorded as a Changed entry since `GOALS.md` asks for breaking changes to be legible in the changelog rather than discovered at compile time, and the crate is reachable as a git dependency regardless of crates.io status. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
d51de3fc63 |
Rule out a CLI in this package
A command-line client over this library is a reasonable thing to want, and the reason is sharper than it was a week ago: the e-invoicing and integration methods return `serde_json::Value` and were verified against mocks rather than a live service, so "what does this endpoint actually return" is now a question the crate cannot answer without a new example per call. It still belongs in a sibling crate rather than this one. An argument parser would be the first dependency here that the library does not itself need, along with the first optional dependency and the first `[features]` section, in a `Cargo.toml` where every line currently justifies itself. It would couple the library's MSRV to a floor that moves on someone else's schedule — not a break today, `clap` 4.6.7 declares 1.85 against this crate's 1.88, so the entry records the figure with the date it was checked. And a CLI's flags are a compatibility surface, which one version number would force to move in lockstep with a library that tells callers to expect breaks in minor releases. For probing, `examples/` already covers it at no cost: `capture_shapes`, `seed_sample_data` and `smoke_test` are CLI-shaped programs configured from the environment, with the `IN_SMOKE_WRITE_HOST` guard to copy for anything that writes. Recorded the same way as the `updated_at` sync engine in the open questions — a different product, written down so the option is not forgotten rather than because it is rejected outright. No changelog entry: nothing about crate behaviour changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
446617a728 |
Wrap the e-invoicing and integration routes
Closes the last roadmap item, and with it the roadmap: every route in
`routes/api.php` that an API-token client can reach is now wrapped. 33
methods — 17 e-invoicing, 4 QuickBooks, 4 Stripe, 6 calendar, and one each
for Yodlee and GoCardless.
Most return `serde_json::Value`, which is deliberate and is the crate's
largest untyped surface. These replies are pass-throughs from Storecove,
Stripe's gateway driver, Yodlee or GoCardless, or arrays assembled for
Invoice Ninja's own React client. None has a documented schema, several
differ by provider, and they move on the provider's release schedule rather
than Invoice Ninja's — so the rule that keeps `chart` generic applies here
with more force, not less. `client_peppol_discovery` set the precedent.
Three upstream behaviours needed accommodating, each now pinned by a test:
- `validate_einvoice` answers 422 when validation finds problems, so an
ordinary "this invoice is not Peppol-ready" result arrives as `Error::Api`
rather than an `Ok` carrying the failures. The per-entity detail is not
reachable through the typed error. Documented rather than worked around.
- `einvoice/peppol/setup` has two success shapes: a `corppass_url` when the
connection needs a further browser step, or a bare 204 when it completed.
Hence `post_unwrapped_opt` and `Option<Value>`, since decoding the 204
would otherwise be a spurious error.
- `einvoice/peppol/remove_additional_legal_identifier` is a DELETE carrying
a body — the only one in the crate — and `einvoice/peppol/update` a PUT
with one, hence `send_unwrapped`.
The Peppol handlers also return `data_get($response, 'message')` as the
entire error body, which may be a bare string rather than
`{"message": …, "errors": {…}}`. `Error::Api` then falls back to an excerpt
with an empty `errors` map; the docs say so on the impl block.
Two things in this block stay unwrapped because they cannot be wrapped. The
OAuth legs of the QuickBooks and calendar flows sit outside the `api/v1`
group, take no token, and answer with redirects, so connecting an account
remains a browser flow — these methods operate a connection that already
exists. And `POST /quickbooks/settings` is a registered route whose
controller has no `settings` method, so it raises `BadMethodCallException`
and 500s; there is nothing to wrap until upstream adds the handler. Both are
now entries in `COVERAGE.md`'s gap list rather than silent omissions.
`GOALS.md` keeps the roadmap rather than deleting it: several entries record
what an item's original reasoning got wrong, which outlasts the fact that it
shipped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
awkawbandClaude Opus 5
|
e6e41fe5c6 |
Wrap the eight invitation-key downloads
`GOALS.md` listed these as "eight routes that take no auth token, so they do
not fit the authenticated request path and need a different entry point."
That was wrong on every count, and wrong in the way goal 6 exists to catch:
the premise came from the route names rather than the route file.
All eight sit inside `routes/api.php`'s `api/v1` group, under its
`token_auth` middleware, and the controllers' own OpenAPI blocks declare
`X-API-TOKEN`. So they needed no new entry point — just a macro, alongside
`entity_action_methods!` and for the same four entities. What the item had
actually described is the client-portal family in `routes/client.php`, which
is genuinely token-less, is not under `/api/v1`, and stays unwrapped for
that reason; it is now the gap entry in `COVERAGE.md`.
`download_{invoice,quote,credit,purchase_order}_by_invitation_key` returns
the PDF and `download_e_*_by_invitation_key` the XML e-document. These take
a contact's invitation key rather than a record id, so the server renders in
that contact's locale — a client with contacts in two languages gets a
different document per key, which the id-based `download_*` cannot express.
Two things here are easy to get wrong, so both are pinned by tests. The
entity segment is singular (`invoice/{key}/download`), the only route family
in the API that departs from the plural CRUD path. And an unknown key is a
400 carrying `no record found`: the controllers return that directly instead
of raising `ModelNotFoundException`, so the status matches the rule for a
missing record but the message does not.
The smoke test's read tier now downloads an invoice by invitation key,
taking the key from the `invitations` array the list route already returns.
It is there to re-check the token claim against a real server rather than
against a second reading of the source. The `download_e_*` four are left
out: they render from e-invoice settings a test instance need not have.
Also in here, unrelated: a rustfmt fix to a `match` arm in
`examples/smoke_test.rs` that was already off-format on main, so
`cargo fmt --check` — and with it CI's `test` job — was failing before this
change. It could not be split out cleanly, being in a file this change also
touches.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
awkawbandClaude Opus 5
|
2532b83a32 |
Point the Gitea links at the renamed repository
The canonical repo is now `awkawb/invoiceninja-sdk`; the old `awkawb/invoiceninja` path only resolves through a redirect. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
0485272080 |
Document the new endpoints and the fixture workflow
Updates the three coverage summaries to 325 methods so they agree, moves the per-resource extras out of the gap list in `COVERAGE.md` now that they are wrapped, and records why the fixtures exist and how to refresh them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
e4f2373b53 |
Add multipart document uploads for the 16 resources that have the route
First item on the GOALS.md roadmap. `upload_{x}(id, files, is_public)`
attaches files through `/{resource}/{id}/upload` and returns the
refreshed record. Verified against upstream that all 16 controllers
answer with `itemResponse($x->fresh())`.
Three details that look wrong but are not, each checked in the upstream
source rather than taken from the published spec:
- The request is a POST carrying `_method=PUT`. The route is registered
PUT, but PHP does not parse a multipart body on a real PUT, so the
files never arrive. Laravel's kernel calls
`enableHttpMethodParameterOverride()`, turning the spoofed method back
into a PUT before routing. The spec documents POST with `_method=POST`,
which would 405 against these routes.
- `is_public` is sent as 1/0. Laravel's `boolean` rule accepts only
true, false, 0, 1, '0' and '1' under strict comparison, so "true"
fails validation.
- Uploads are never retried. An upload adds a document, so it is not
idempotent whatever its verb, and a replay after a lost response would
attach the file twice. This falls out of reqwest's multipart body being
un-cloneable, which nothing in the types enforces, so a test pins it
for 500, 503 and 429.
An upload with no files, a nameless file or an unparseable MIME type is
refused locally (`Error::InvalidUpload`), since the server answers an
empty upload with a success that changed nothing.
Corrects two earlier claims:
- GOALS.md and COVERAGE.md said uploads would make `create_document`
possible. They do not: `DocumentController::store` is an empty stub,
and an upload is the only way a document is created. There is no
`create_document`.
- The documented method count (265) had been stale since the typed
`statics`/`search`/`health_check` commit, which added three `_as`
methods without updating it. Recounted from the source: 284 = 210 +
18 + 12 + 16 uploads + 28 hand-written.
Also fixes a README example, `let statics: Value = client.statics()`,
that stopped compiling when `statics` lost its type parameter.
`edocument/upload` is left out: it imports an expense from an
e-document rather than attaching a file, so it moves to the
import/export roadmap item.
Enabling `multipart` adds mime, mime_guess and unicase; MSRV stays 1.88,
re-verified by running the suite on it. 101 tests, up from 91.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
awkawbandClaude Opus 5
|
355cf08324 |
Point at the GitHub mirror and document that it is read-only
`Cargo.toml` named github.com/bryant/invoiceninjars, a guess from the git author name that was never a real repository. It now points at the mirror that actually exists, so the crates.io "Repository" link will resolve. Gitea is the source of truth and a push mirror copies every commit to GitHub. Anything written to the GitHub copy is overwritten by the next sync, so a merged pull request there would silently vanish. README and GOALS.md say so, and direct issues and pull requests to Gitea. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
a7d8300ce9 |
Narrow the ORM/caching non-goal to what is actually ruled out
"No ORM, session, or caching layer" bundled several decisions with very different costs, and read as refusing things that are in fact fine. Split into the three that genuinely conflict, each with its reason: lazy loading (models would have to hold a client handle, breaking `Default`-constructibility and the `extra` round trip), dirty tracking (cannot diff a flattened map of unmodelled fields), and transparent entity caching. The caching reason is the one worth recording: `BaseController`'s shared response path sends no `ETag`, `If-None-Match`, or `Cache-Control`, so a cached entity cannot be cheaply revalidated. On an API that handles money that is a correctness hazard rather than a missed optimisation. Writing the evidence down so the question is not reopened without it. Two things the old wording excluded by accident are now open questions instead: typed `include` helpers, since eager loading is a stringly parameter where a typo is a silent no-op; and an opt-in cache for `/statics`, which is near-constant and not money. Also parks the `updated_at` delta-sync parameter as the shape a local mirror would need, noted as a different product rather than a plan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
awkawbandClaude Opus 5
|
fbde9a9bb7 |
Write down the project's goals, non-goals, and roadmap
Several decisions in here look like oversights until you know the reasoning: the curated model subset with everything else in `extra`, the still-generic `chart`, not retrying `POST`, the deliberate divergences from the official PHP SDK. That reasoning was spread across code comments and commit messages, where it is easy to miss and easy to "fix". GOALS.md states: - What the crate is for: complete coverage, and not quietly losing data, truncating results, or succeeding when it did not. - Seven goals, each tied to a decision visible in the code, so the rationale survives the next refactor. - Non-goals, including no sync API, no caching or ORM layer, no modelling of every field, and no retrying of non-idempotent requests. - Publication posture: on crates.io, pre-1.0, no stability promise, pin an exact version. MSRV may rise with dependencies. - A roadmap ordering the COVERAGE.md gaps by value over effort, starting with multipart uploads, which is the only thing blocking `create_document`. - Open questions, left open rather than papered over: whether auth routes belong here at all given they are a different auth model, whether per-chart types earn their keep, streaming for large exports, and the untested `Error::PaginationLimit`. README, COVERAGE.md, and CLAUDE.md link to it. No changelog entry: this adds no behaviour, per the rule in CLAUDE.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |