domain-contract · planned
Cadastros pendentes de supervisor e concedente
Contrato de dados e análise dos cadastros solicitados durante a abertura de estágio.
Regras comuns
| Campo | Regra |
|---|---|
id | bigint, chave primária. |
status | draft, submitted, under_review, approved, rejected ou cancelled; enum existente RegistrationRequestStatus. |
reviewed_at | nullable até a análise; registra o instante da revisão. |
decision_reason | obrigatório em recusa ou cancelamento; opcional em aprovação. |
| timestamps | auditoria técnica; alterações e decisões relevantes também entram no activity_log. |
Em draft, campos de negócio podem ser nulos. Em todos os demais estados, as colunas obrigatórias do respectivo cadastro devem ser válidas. Na Migration 19, a solicitação de estágio identifica o vínculo discente responsável pelo envio. As Migrations 12A e 12B não duplicam FKs de autoria ou revisão nem guardam submission_snapshot; quando seus Models forem alterados por Eloquent, o Activity Log registra eventos e o contexto de autoria disponível. As Actions e Policies dos fluxos de análise ainda estão pendentes. Aprovação não cria automaticamente conta ou concedente sem uma ação de análise explícita do Setor.
supervisor_registration_requests
| Campo | Regra |
|---|---|
name | obrigatório fora de rascunho. |
cpf | informado pelo discente, válido e normalizado; obrigatório fora de rascunho. |
phone / email | obrigatórios fora de rascunho e normalizados. |
job_role | obrigatório fora de rascunho. |
qualification | obrigatório fora de rascunho. |
training | nullable; formação declarada. |
professional_experience | texto nullable; experiência profissional declarada. |
supervisor_affiliation_id | FK nullable para o vínculo criado ou selecionado na aprovação; obrigatório quando status = approved. |
Este pedido registra a proposta do discente e a análise do Setor. Os dados profissionais atuais ficam em user_personal_data, compartilhados pelos vínculos da mesma conta. Se já houver um vínculo de supervisor selecionável, a solicitação de estágio pode referenciá-lo diretamente e não precisa criar este pedido. Quando houver pendência, o registro mantém os dados profissionais enviados; após aprovação, associa um vínculo de supervisor existente ou criado em transação. No aceite, os dados necessários são copiados para internships.supervisor_snapshot.
A Migration 12A guarda o CPF informado pelo discente em coluna própria, validado e normalizado pelo CpfCast; users.cpf continua único na conta. A associação a uma conta existente ou a criação da conta e do vínculo será feita no futuro fluxo de aprovação. Cargo, qualificação, formação e experiência atuais ficam em user_personal_data. O supervisor preenche ou confirma esses dados no futuro formulário, e cada estágio conserva seu próprio snapshot histórico.
granting_party_registration_requests
| Campo | Regra |
|---|---|
campus_id | FK obrigatória para o campus de origem, com exclusão restrita; não pode ser alterada após a criação. |
document_type / document_number | tipo CPF/CNPJ e número normalizado; obrigatórios fora de rascunho. |
name | nome ou razão social, obrigatório fora de rascunho. |
street, number, neighborhood, city, uf, zip_code | endereço proposto, obrigatório fora de rascunho. |
representative_name / representative_role | obrigatórios fora de rascunho. |
phone / email | nullable e normalizados. |
field_of_activity | obrigatório fora de rascunho. |
professional_council / council_registration_number | nullable. |
credentialing_process_number | nullable. |
granting_party_id | FK nullable para o cadastro criado ou selecionado; obrigatório quando status = approved. |
Na aprovação, o Setor cria ou seleciona uma granting_parties do mesmo campus de origem do pedido. A regra de campus está validada no Model. Uma concedente nova recebe uma linha própria em addresses, mesmo que outro cadastro tenha endereço idêntico; o pedido preserva o endereço proposto em suas colunas. O CNPJ da matriz pode aparecer em registros distintos para filiais ou escolas, e CPF/CNPJ não devem provocar compartilhamento automático entre campi. A solicitação pendente mantém o envio original, a decisão e o vínculo resultante, enquanto a tabela de concedentes guarda somente o cadastro atual. Tanto a concedente quanto a solicitação de concedente persistem campus_id, que não pode ser alterado após a criação.
Integridade e interface
- A solicitação de estágio referencia uma concedente ou uma solicitação pendente, e um supervisor ou uma solicitação pendente; cada par é exclusivo.
- O discente pode continuar preenchendo o formulário principal enquanto o cadastro estiver em análise, mas não pode enviar a abertura para aceite até as duas referências exigidas estarem aprovadas.
- Só o Setor visualiza e decide as solicitações pendentes; elas não são logs expostos ao discente ou ao supervisor.
- Recusar ou cancelar não apaga o registro. O discente pode escolher um cadastro existente ou criar nova solicitação, preservando o histórico da anterior.