Add schema to download_all and series_autonumber_range

[alesan99]

Fixes #7596

Adds API schemas to the endpoints I added before.

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add automated tests

Testing instructions

• This is a pretty simple PR to test. Its just a documentation update.
• Go to http://localhost/documentation/api/operations/all/
• Find and make sure the schema for /specify/attachment_gw/download_all looks correct. The request body should now be there.
• Find and make sure the schema for /specify/series_autonumber_range looks correct. The request body should now be there.

Summary by CodeRabbit

• Documentation

  • API docs updated: file-download endpoint now documents JSON request options and a binary ZIP response; series auto-numbering endpoint now documents required inputs and response shape.

• Chores

  • Formatting, whitespace and test formatting cleanups across the frontend.
  • Minor localization and language-configuration refinements.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds OpenAPI schema decorators to two backend endpoints (download_all and series_autonumber_range) and applies formatting/whitespace changes across multiple frontend TypeScript/React files. No runtime behavior, endpoint signatures, or exported/public APIs were changed.

Changes

API Schema Documentation

Layer / File(s)	Summary
Schema Definitions specifyweb/backend/attachment_gw/views.py, specifyweb/backend/series/views.py	Added @openapi(schema=...) decorators: download_all documents a JSON requestBody (either attachmentlocations+origfilenames or recordsetid) and a 200 binary zip response; series_autonumber_range documents required JSON inputs (rangestart, rangeend, tablename, fieldname, formattername) and the 200 response schema. No endpoint logic changed.

Frontend Formatting & Configuration

Layer / File(s)	Summary
Component & Logic Reformatting specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/..., specifyweb/frontend/js_src/lib/components/FormCells/FormTable.tsx, specifyweb/frontend/js_src/lib/components/Header/..., specifyweb/frontend/js_src/lib/components/Notifications/NotificationRenderers.tsx, specifyweb/frontend/js_src/lib/components/DataModel/businessRuleDefs.ts, specifyweb/frontend/js_src/lib/components/WbPlanView/navigator.ts, specifyweb/frontend/js_src/lib/utils/schemaVisibility.ts	Whitespace, line-wrapping, and minor formatting changes across many components (multiline destructuring, JSX rewrapping, dynamic import formatting). Behavior, callbacks, and control flow remain unchanged.
Tests specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/__tests__/*	Test fixtures and assertions were reformatted (multiline expect blocks, array literals, spacing). Test logic and expectations unchanged.
Localization & Config specifyweb/frontend/js_src/lib/localization/common.ts, specifyweb/frontend/js_src/lib/localization/utils/config.ts	Reformatted string literal for expressSearchInstructions and changed languageCodeMapper entry from 'nb': 'nb_NO' to nb: 'nb_NO' (identifier key). No functional change to translations.

🚥 Pre-merge checks | ✅ 3 | ❌ 3

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	Most changes are formatting/whitespace adjustments unrelated to the schema additions. The scope-creep includes reformatting of frontend components and tests that are outside the stated objectives.	Remove unrelated formatting changes in frontend files (ExpressSearchConfig, FormTable, Header, Notifications, localization, etc.) to keep the PR focused on schema additions per issue #7596.
Automatic Tests	⚠️ Warning	PR adds @openapi schema decorators but explicitly acknowledges 'add automated tests' as incomplete in the checklist, with no new or updated tests provided.	Add automated tests to verify @openapi schema decorators are properly registered and accessible through the API documentation endpoint.
Testing Instructions	⚠️ Warning	Testing instructions lack specificity on what to verify, expected schema structure, setup steps, and whether automated tests are required.	Clarify what specific schema validations should be performed, provide local environment setup steps, list expected fields/types for each endpoint, and specify if automated tests must be added.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main changes: adding OpenAPI schemas to the download_all and series_autonumber_range endpoints.
Linked Issues check	✅ Passed	The PR successfully addresses issue #7596 by adding OpenAPI schemas to both missing endpoints (download_all and series_autonumber_range) to make them appear in API documentation.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue-7596

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

specifyweb/backend/series/views.py (1)

35-52: ⚡ Quick win

Document 400/500 responses to match actual endpoint behavior.

The view returns 400 for invalid ranges and 500 for unexpected failures, but the schema only advertises 200. Adding these responses will make generated API clients and docs more accurate.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@specifyweb/backend/series/views.py` around lines 35 - 52, The OpenAPI
responses dict in the view currently only documents a 200 response; update the
responses mapping used in the view's "responses" definition to also include
"400" and "500" entries that reflect actual behavior: add a "400" response with
description like "Invalid range" and a JSON schema with an "error" string (and
optionally "details"), and add a "500" response with description like "Internal
server error" and a JSON schema containing an "error" string; modify the same
responses object used by the view (the "responses" dict in the view
function/class) so generated docs and clients show these status codes.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@specifyweb/backend/attachment_gw/views.py`:
- Line 331: Fix the typo in the API description for the recordsetid field:
locate the dictionary entry where the "description" for "recordsetid" is defined
in attachment_gw/views.py and replace "attachmends" with the correct word
"attachments" so the description reads "Optional. Will download all attachments
in the recordset. Using this will ignore all other properties."
- Around line 329-335: The JSON schema currently requires "attachmentlocations"
and "origfilenames" unconditionally which contradicts the intent that a request
may supply only "recordsetid"; update the schema object that defines
"recordsetid" so it expresses the two allowed shapes (either recordsetid-only OR
attachmentlocations+origfilenames). Replace the flat "required":
["attachmentlocations","origfilenames"] with an anyOf (or oneOf) that has two
subschemas: one requiring ["recordsetid"] and the other requiring
["attachmentlocations","origfilenames"]; keep the existing property definitions
for "recordsetid", "attachmentlocations", and "origfilenames" intact. Ensure the
change is made in the same schema dict in views.py where the "recordsetid"
property and "required" list currently appear.

---

Nitpick comments:
In `@specifyweb/backend/series/views.py`:
- Around line 35-52: The OpenAPI responses dict in the view currently only
documents a 200 response; update the responses mapping used in the view's
"responses" definition to also include "400" and "500" entries that reflect
actual behavior: add a "400" response with description like "Invalid range" and
a JSON schema with an "error" string (and optionally "details"), and add a "500"
response with description like "Internal server error" and a JSON schema
containing an "error" string; modify the same responses object used by the view
(the "responses" dict in the view function/class) so generated docs and clients
show these status codes.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3ec47463-645b-49a0-9ccf-d7c1fe3a0cfc

📥 Commits

Reviewing files that changed from the base of the PR and between 753a2cf and 16722fa.

📒 Files selected for processing (16)

• specifyweb/backend/attachment_gw/views.py
• specifyweb/backend/series/views.py
• specifyweb/frontend/js_src/lib/components/DataModel/businessRuleDefs.ts
• specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/ExpressSearchConfigDialog.tsx
• specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/ResultsOrderingTab.tsx
• specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/__tests__/ExpressSearchConfigEditor.test.tsx
• specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/__tests__/RelatedTablesTab.test.tsx
• specifyweb/frontend/js_src/lib/components/ExpressSearchConfig/__tests__/ResultsOrderingTab.test.tsx
• specifyweb/frontend/js_src/lib/components/FormCells/FormTable.tsx
• specifyweb/frontend/js_src/lib/components/Header/ExpressSearchHooks.tsx
• specifyweb/frontend/js_src/lib/components/Header/ExpressSearchTask.tsx
• specifyweb/frontend/js_src/lib/components/Notifications/NotificationRenderers.tsx
• specifyweb/frontend/js_src/lib/components/WbPlanView/navigator.ts
• specifyweb/frontend/js_src/lib/localization/common.ts
• specifyweb/frontend/js_src/lib/localization/utils/config.ts
• specifyweb/frontend/js_src/lib/utils/schemaVisibility.ts

[CarolineDenis]

@alesan99 could you:

• merge main into this pr and resolve any conflicts
• write a complete summary of what has been done
• add a detailed description of what is left to do, along with guidance on how to proceed

[alesan99]

This PR is complete and ready to be tested.

It adds descriptions to the API documentation for download_all and series_autonumber_range, no functionality has been changed.

[emenslin]

• Find and make sure the schema for /specify/attachment_gw/download_all looks correct. The request body should now be there.
• Find and make sure the schema for /specify/series_autonumber_range looks correct. The request body should now be there.

Looks good, the request body is now there for both.

[Iwantexpresso]

• Find and make sure the schema for /specify/attachment_gw/download_all looks correct. The request body should now be there.

• Find and make sure the schema for /specify/series_autonumber_range looks correct. The request body should now be there.

the documentation looks clean, nice work!