> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # id, label and code for a picker, for any entity — choosable is not the same as editable. > `code` is the register's own short identifier where it has one — the asset number, the part number, the site code. Names are unique on almost none of these tables, so a picker labelled by name alone offers two identical rows and no way to tell which is which; this is the column that settles it, and the search matches it as well as the name. A register that is a tree answers with its depth and its readable path as well, so the picker draws the hierarchy rather than a flat alphabetical list of leaves. `p_for_entity` names the form doing the asking, which only `config.states` needs: it holds every entity's states and a form wants its own. The scope narrows the list to one parent's rows, which is what makes a two-hundred-row subdivision list usable. `p_scope_optional` lets that run the other way: with no scope id it returns the whole register instead of nothing, and every row carries its own value of the scope column, so a form may offer the child first and fill the parent in from whichever one gets chosen. `p_for_record_id` names the record being edited, which matters on the fourteen columns that point back at their own register: it and everything already inside it come out of the list, because a record cannot be filed under itself. `p_at_site_id` names the site the form has reached, which only `core.asset_categories` reads: a class of asset says where it exists, inheriting the rule of the nearest category above it, and a picker on a form that has named a site offers what that site has. A form that has not named one narrows nothing. `p_at_location_id` and `p_in_category_id` are the other two things a form may already have settled, and three registers read them. An asset is offered at the place and in the class the form named, and in every class beneath that one, so a job raised about a centrifugal pump is not asked to find it among fifty thousand. A kind of job and a level of urgency are offered where the tenant said they apply: an empty set of sites or of classes means everywhere rather than nowhere, so a register nobody has scoped is offered whole. A kind of job restricted to particular roles is also offered only to a caller holding one of them, which is a rule about the reader rather than about the form and so applies whatever else has been named. `p_keep_id` is the row the form already names, and it comes back through every one of those narrowings and through the exclusion of an asset that has left service. Narrowing a picker on a record that exists is not the same act as narrowing one on a blank form: a pump moved to the workshop is still the machine the job is about, and a list that dropped it would leave the control with nothing to label the value it is holding. It does not reopen what the register excludes — a deleted row stays gone, and a row cannot be offered as its own parent. `choosable` appears when the caller names the field it is asking on behalf of and the organisation has said that field is answered with the last level of its tree: false marks a row with something under it, which the picker draws as a heading rather than a choice. The rows are all still there — a branch is how somebody finds and reads what is under it — and leaf is relative to this list, so a branch whose every child is scoped out of this site is choosable here. A caller that names no field is answered without the key at all, which is every picker that reads a tree in order to scope a rule rather than to file a record. The order is the register's own arrangement where it has one — the column a person dragged the list into, or the `sort_order` a register with no admin screen carries anyway — with the name as the tie-break. Everything else is alphabetical by name. A tree is ordered so that a parent comes immediately above its own children, by path where the register has no arrangement and by the arrangement at each level where it has one, so that the indent and the order a person chose are both true of the same list. `p_ids` asks for the labels of particular rows instead of a page of the register: what a picker needs when the value already chosen is not among the first rows it was shown, which on a register of tens of thousands is most of them. The answer is those rows, as the list would label them, and nothing else. ## OpenAPI ````yaml /api-reference/openapi.json get /rpc/list_options openapi: 3.0.0 info: description: '' title: >- The only schema PostgREST exposes. Reads are security_invoker views; writes are SECURITY DEFINER functions. Rebuilt wholesale on every deploy — it holds no data. version: 12.2.3 servers: - url: https://app.assetinfinity.ai/api security: [] tags: - name: Signing in - name: Profile - name: Assets - name: Asset lifecycle - name: Work lifecycle - name: Maintenance - name: Inventory - name: Inventory detail - name: Procurement - name: Contracts - name: Workforce - name: Capacity - name: Dispatch - name: Tools - name: Inspections - name: Verification - name: Reliability - name: Parts demand - name: Sensors and meters - name: Map - name: Floor plans - name: Labels - name: Lost and found - name: Root cause analysis - name: Reports - name: Audit center - name: Activity - name: Notifications - name: Channels - name: Search - name: Copilot - name: Import - name: Files - name: Sync - name: Support - name: Admin - name: Access - name: Lookups - name: Read models - name: Branding - name: Custom fields - name: Form studio - name: Workflows - name: Workflow studio - name: Rules - name: Statuses and transitions - name: Currencies and locales - name: Work configuration - name: Asset configuration - name: Inventory configuration - name: Tool configuration - name: Workforce configuration - name: Vendor and contract configuration - name: Document configuration - name: Inspection configuration - name: Sites, locations and the organisation - name: Platform - name: Amendments - name: Asset clone - name: Asset components - name: Asset register - name: Asset transfer - name: Audit feed - name: Billing - name: Bookings - name: Budgets - name: Bulk jobs - name: Calibration history - name: Capex plans - name: Conversations - name: Costing - name: Currency - name: Dashboards - name: Directory sync - name: Document control - name: Document folders - name: Document tree - name: Documents - name: Energy - name: Extracts - name: Features - name: Feeds - name: File exchange - name: Filing exceptions - name: Finance - name: Inbound mail - name: Keys - name: Knowledge - name: Licence - name: List views - name: Locations - name: Mapping - name: Mcp - name: Mcp oauth - name: Mfa - name: Numbering - name: Permits - name: Readers - name: Reference - name: Reference columns - name: Reference entry - name: Release - name: Scim - name: Security streams - name: Self verification - name: Setup - name: Shutdown - name: Sso - name: Telegram - name: Tenant switch - name: The caller's own work - name: The checklist library - name: Tools on a job, and who has them out - name: Tray - name: Vendor spend forecast - name: Vendors and contracts - name: Visitors - name: Work order execution - name: Work sequencing - name: Workforce detail externalDocs: description: PostgREST Documentation url: https://postgrest.org/en/v12/references/api.html paths: /rpc/list_options: get: tags: - Admin summary: >- id, label and code for a picker, for any entity — choosable is not the same as editable. description: >- `code` is the register's own short identifier where it has one — the asset number, the part number, the site code. Names are unique on almost none of these tables, so a picker labelled by name alone offers two identical rows and no way to tell which is which; this is the column that settles it, and the search matches it as well as the name. A register that is a tree answers with its depth and its readable path as well, so the picker draws the hierarchy rather than a flat alphabetical list of leaves. `p_for_entity` names the form doing the asking, which only `config.states` needs: it holds every entity's states and a form wants its own. The scope narrows the list to one parent's rows, which is what makes a two-hundred-row subdivision list usable. `p_scope_optional` lets that run the other way: with no scope id it returns the whole register instead of nothing, and every row carries its own value of the scope column, so a form may offer the child first and fill the parent in from whichever one gets chosen. `p_for_record_id` names the record being edited, which matters on the fourteen columns that point back at their own register: it and everything already inside it come out of the list, because a record cannot be filed under itself. `p_at_site_id` names the site the form has reached, which only `core.asset_categories` reads: a class of asset says where it exists, inheriting the rule of the nearest category above it, and a picker on a form that has named a site offers what that site has. A form that has not named one narrows nothing. `p_at_location_id` and `p_in_category_id` are the other two things a form may already have settled, and three registers read them. An asset is offered at the place and in the class the form named, and in every class beneath that one, so a job raised about a centrifugal pump is not asked to find it among fifty thousand. A kind of job and a level of urgency are offered where the tenant said they apply: an empty set of sites or of classes means everywhere rather than nowhere, so a register nobody has scoped is offered whole. A kind of job restricted to particular roles is also offered only to a caller holding one of them, which is a rule about the reader rather than about the form and so applies whatever else has been named. `p_keep_id` is the row the form already names, and it comes back through every one of those narrowings and through the exclusion of an asset that has left service. Narrowing a picker on a record that exists is not the same act as narrowing one on a blank form: a pump moved to the workshop is still the machine the job is about, and a list that dropped it would leave the control with nothing to label the value it is holding. It does not reopen what the register excludes — a deleted row stays gone, and a row cannot be offered as its own parent. `choosable` appears when the caller names the field it is asking on behalf of and the organisation has said that field is answered with the last level of its tree: false marks a row with something under it, which the picker draws as a heading rather than a choice. The rows are all still there — a branch is how somebody finds and reads what is under it — and leaf is relative to this list, so a branch whose every child is scoped out of this site is choosable here. A caller that names no field is answered without the key at all, which is every picker that reads a tree in order to scope a rule rather than to file a record. The order is the register's own arrangement where it has one — the column a person dragged the list into, or the `sort_order` a register with no admin screen carries anyway — with the name as the tie-break. Everything else is alphabetical by name. A tree is ordered so that a parent comes immediately above its own children, by path where the register has no arrangement and by the arrangement at each level where it has one, so that the indent and the order a person chose are both true of the same list. `p_ids` asks for the labels of particular rows instead of a page of the register: what a picker needs when the value already chosen is not among the first rows it was shown, which on a register of tens of thousands is most of them. The answer is those rows, as the list would label them, and nothing else. parameters: - in: query name: p_entity required: true schema: format: text type: string - in: query name: p_search required: false schema: format: text type: string - in: query name: p_scope_column required: false schema: format: text type: string - in: query name: p_scope_id required: false schema: format: uuid type: string - in: query name: p_for_entity required: false schema: format: text type: string - in: query name: p_for_record_id required: false schema: format: uuid type: string - in: query name: p_at_site_id required: false schema: format: uuid type: string - in: query name: p_at_location_id required: false schema: format: uuid type: string - in: query name: p_in_category_id required: false schema: format: uuid type: string - in: query name: p_keep_id required: false schema: format: uuid type: string - in: query name: p_scope_optional required: false schema: format: boolean type: boolean - in: query name: p_starting_only required: false schema: format: boolean type: boolean - in: query name: p_for_column required: false schema: format: text type: string - in: query name: p_ids required: false schema: format: uuid[] type: string responses: '200': description: OK ````