Josep Piguillem
82ef2b38dd
/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>
34 lines
964 B
PHP
34 lines
964 B
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Http\Requests\Api\V1\Concerns;
|
|
|
|
use Illuminate\Validation\Validator;
|
|
|
|
/**
|
|
* Publishing is a permission of its own, as in the panel — where these fields
|
|
* are disabled for whoever lacks it. Here they are refused, so someone who may
|
|
* write a record still cannot put it on the site, or take it off, alone.
|
|
*/
|
|
trait GuardsPublication
|
|
{
|
|
/**
|
|
* @param array<int, string> $fields
|
|
*/
|
|
protected function guardPublication(Validator $validator, string $permission, array $fields): void
|
|
{
|
|
$validator->after(function (Validator $validator) use ($permission, $fields): void {
|
|
if ($this->user()?->can($permission)) {
|
|
return;
|
|
}
|
|
|
|
foreach ($fields as $field) {
|
|
if ($this->has($field)) {
|
|
$validator->errors()->add($field, __('rules.publication.forbidden'));
|
|
}
|
|
}
|
|
});
|
|
}
|
|
}
|