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.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

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.

PHP Laravel

Cresce com a tua app. Uma aplicação simples usa só Settings::get() / Settings::set() — a migration cria as duas tabelas do pacote, mas settings_managers fica vazia e sem custo até precisares dela. Uma aplicação com multitenancy e controlo de acesso granular activa is_inheritable, visibility e SettingManager::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 globaluser:42:

Modo SaaS multitenant

Copia de tenant:5globaluser: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

PHP Build Version
Package Version
Requires php Version ^8.2
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
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package gsebastiao/laravel-settings contains the following files

Loading the files please wait ...