The project form gets «Crear en TaskStream» while the project has no
board, and `taskstream: true` on a PATCH does the same through the API.
A refusal leaves the edit unsaved; a project with a board keeps it, and
`taskstream_key` without the flag is still ignored.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`taskstream: true` on POST /v1/projects also creates the project in
TaskStream, public, as the caller (their Pireon token is passed on), and
the answer carries `taskstream_key` and `taskstream_url`. The key is
`taskstream_key` or one made from the default-language slug.
The board is opened before the project is saved: if TaskStream refuses
it, nothing is created here and the reason comes back as a validation
error (502 when TaskStream does not answer). Machine tokens need the
server's own TASKSTREAM_TOKEN. Updates ignore the flag, and duplicates do
not inherit the link.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
/api/v1/projects, /members and /services: create, list, show, update,
delete and restore, with the panel's own rules — so the MCP server can
load the collective's work, people and offer without anyone retyping
them into forms. The MCP server picks the tools up from openapi.yaml.
- Relations travel as ids and are replaced whole when sent, left alone
when not: a project's technology_ids, service_ids and members with
each one's role; a member's technology_ids; a service's
technology_ids and project_ids. Record and relations are saved in
one transaction.
- Publishing stays a permission of its own. Without projects.publish
or services.publish, published_at, unpublish_at and is_published are
refused — the fields the panel disables for the same people.
- MemberPolicy still lets someone edit their own profile.
- Uploads accept `for: projects` and `for: members`, landing where the
panel's own upload fields put them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
