Download the PHP package gsebastiao/laravel-settings without Composer
On this page you can find all versions of the php package gsebastiao/laravel-settings. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download gsebastiao/laravel-settings
More information about gsebastiao/laravel-settings
Files in gsebastiao/laravel-settings
Package laravel-settings
Short Description Pacote Laravel para gestão de settings com chave composta, hierarquia de contexto (global → tenant → user) e cast dinâmico.
License MIT
Homepage https://github.com/gsebastiao/laravel-settings
Informations about the package laravel-settings
Laravel Settings
Pacote Laravel para gestão de settings com chave composta, hierarquia de contexto (global → tenant → user) e cast dinâmico de valores.
Cresce com a tua app. Uma aplicação simples usa só
Settings::get()/Settings::set()— a migration cria as duas tabelas do pacote, massettings_managersfica vazia e sem custo até precisares dela. Uma aplicação com multitenancy e controlo de acesso granular activais_inheritable,visibilityeSettingManager::grant()sem tocar no código já escrito, nem correr uma segunda migration.
Instalação
O pacote usa auto-discovery — o SettingsServiceProvider e o alias Settings são registados automaticamente.
Corre a migration:
Publicar recursos (opcional)
Configuração
Após publicar, edita config/settings.php:
Ou via .env:
Uso
Helper global setting()
Facade Settings::
Injecção de dependência
Hierarquia de contexto
| Context helper | Resultado |
|---|---|
SettingsService::globalContext() |
'global' |
SettingsService::userContext() |
'user:42' (autenticado) |
SettingsService::userContext(99) |
'user:99' |
SettingsService::userContext($model) |
'user:{$model->id}' |
SettingsService::tenantContext(5) |
'tenant:5' |
Cast dinâmico
O value é sempre guardado como texto. O campo cast controla a deserialização:
cast |
Tipo PHP retornado |
|---|---|
string |
string |
int |
int |
float |
float |
bool |
bool |
json / array |
array |
date |
Carbon |
Se não especificares cast, é inferido automaticamente a partir do valor:
is_locked — bloquear overrides
metadata — dados para o frontend
is_inheritable — o que é copiado para novos utilizadores
Por padrão, nenhuma setting é herdada quando um utilizador é cadastrado. Isto evita que configurações internas (versão da app, credenciais de mail, chaves de API) acabem copiadas para cada utilizador sem necessidade.
Marca explicitamente as settings que fazem sentido no contexto do utilizador:
Ver a secção Herança de settings para o fluxo completo de cópia.
visibility — o que o utilizador vê e edita
Cada setting tem uma visibilidade padrão, aplicada a qualquer utilizador que não tenha uma regra específica no controlo de acesso opcional:
| Valor | Efeito |
|---|---|
hidden |
O utilizador não sabe que a setting existe |
readonly |
O utilizador vê o valor mas não pode alterar |
editable |
O utilizador vê e pode personalizar (padrão) |
Numa app simples que só usa Settings::get() / Settings::set(), isto é
tudo o que precisas — o visibility da própria setting já resolve o caso comum
sem qualquer tabela ou configuração extra.
Controlo de acesso granular (opcional em uso) — SettingManager e SettingsAccessControl
Se precisares de dar a um utilizador ou role específico acesso diferente do
padrão — por exemplo, um manager que pode ver o billing.plan normalmente
escondido dos outros utilizadores do tenant — usa a tabela settings_managers
para isso.
A tabela é criada automaticamente junto com settings — a mesma migration
cuida das duas, para evitar dependência entre passos de instalação. Isto não
significa que precises de a usar: enquanto nunca chamares SettingManager::grant(),
fica vazia e nenhuma query extra é feita — o visibility da própria setting
continua a ser a única regra em vigor.
Se preferires nem ter a tabela na base de dados, tens duas opções:
Nos dois casos, o SettingManager::tableExists() detecta a ausência da
tabela em runtime e o SettingsAccessControl ignora o pivot automaticamente,
sem lançar excepção.
Conceder e revogar acesso
Quando existe um registo no pivot para o utilizador (directamente, ou através
de um dos seus roles), esse visibility sobrepõe sempre o da setting —
mesmo que a setting esteja hidden por padrão. Match directo por utilizador
tem prioridade sobre match por role.
Verificar o que o utilizador pode ver/editar
Resolução de roles do utilizador
Por padrão, o SettingsAccessControl tenta chamar $user->getRoleNames()
(compatível com spatie/laravel-permission). Se usares outra solução de
roles, define um resolver próprio em config/settings.php:
Quando um utilizador é cadastrado, podes copiar as settings do contexto global (ou do tenant) para o contexto pessoal do utilizador. Depois disso, o utilizador pode personalizar as suas próprias settings livremente.
Modo normal (sem multitenancy)
Copia todas as settings de global → user:42:
Modo SaaS multitenant
Copia de tenant:5 → global → user:42 (tenant sobrepõe global):
Copiar só namespaces específicos
Pré-visualizar antes de copiar (dry run)
Repor settings de um utilizador (reset)
Apaga os registos user:X e volta a copiar das fontes:
Relatório de cópia
O método forUser() e resetUser() retornam sempre um relatório:
Helpers disponíveis
Estrutura do pacote
Testes
Licença
MIT © Gsebastiao
All versions of laravel-settings with dependencies
illuminate/database Version ^10.0|^11.0|^12.0|^13.0
illuminate/support Version ^10.0|^11.0|^12.0|^13.0
illuminate/cache Version ^10.0|^11.0|^12.0|^13.0