macro_rules! function {
( $($definition:tt)* ) => { ... };
}Expand description
Define and export one apiplant function from a plain handler.
Only name, description, method and handler are required:
apiplant_function::function! {
name: "greet", // URL segment → /functions/greet
version: "1.2.0", // optional; defaults to CARGO_PKG_VERSION
description: "Greets people",
method: Post, // Get | Post | Put | Delete
permission: "role:admin", // public | authenticated | member | role:<name> | private
handler: greet, // fn(&Context<C>, I) -> Result<O, E>
}§Access
permission uses the same grammar as a resource’s [permissions], so an
app has one access vocabulary rather than two. The older
visibility: RoleGated + role: "admin" pair still works and means exactly
what it always did; give one or the other, not both.
member — any member of the caller’s active organisation — is the level
most operator-facing actions want and the reason permission exists;
visibility cannot express it.
§Appearing in the dashboard
The optional admin block controls how apiplant admin presents the
function. Every key is optional:
apiplant_function::function! {
name: "reindex_catalogue",
description: "Rebuilds the product search index.",
method: Post,
permission: "role:admin",
admin: {
visible: true, // default: true unless private
roles: ["admin", "manager"], // who sees it; default: anyone who may call it
label: "Rebuild search index",
group: "Maintenance",
description: "Run this after a bulk import.",
confirm: "Rebuild the index for every product?",
run_label: "Rebuild index",
order: 10,
},
handler: reindex,
}This is presentation only — hiding a function from the dashboard does not
close its endpoint. permission is what does that.
To export several functions from one library, use functions! — this is
exactly that macro with a single entry.