One row table model for settings like purpose about laravel-administrator

[janhartigan]

Before 3.0.0 is released, I plan on allowing optional per-model action permissions. So this would work something like this:

'actions' => array(
    'delete' => function() {return false},
    'create' => function() {return false},
)

With the other one being "edit", I think. I'd leave "read" out because reading data for a model would be the base level of access given in the model's "permission" option.

[andrewdworn]

Let me explain in more details what i meant originally:
I would like to use a db table in a single row model, so i can have all kinds of nice Fields together - but i only need one row. It comes handy when i want to create a "Website's general settings" sort of menu in administrator alongside the real table models.
So a "hack" would look something like this, after selecting menu:

1. No need of table list, because we use only one row
2. No need of create button, because we wanna keep using one row
3. No need of Filter box at all
4. Need of a nicely expanded Edit box (maybe full screen), showing the fields of the only table's row (for simplicity can use id=1)
5. No need of Delete (previous comment comes handy!), only Cancel and Save buttons in Edit box

Being able to do these steps would do the job for me, but you may consider implementing some similar "Set of Fields" model deeper in administrator - alongside the good old table model.

I could do 3. before; i love Filtering, but in tables with few lines (and also with many fields) comes handy to turn it off.

[janhartigan]

1. is a bit tricky to handle at the moment, but I'll try to think of some ways to handle it.
2. is now possible with this commit.
3. is something I've been thinking about, but for now I'm keeping that out of 3.0.0. It's a problem that the filter area is still there when no filter fields are present, but doesn't break the app so I will likely put it in 3.1.0.
4. This would go hand-in-hand with the first item, so I'm thinking of some way to handle this nicely.
5. Also now possible due to aforementioned commit.

As you mention, there may be a smarter way of handling this without bringing up the table data at all. Thinking about it...

[janhartigan]

So earlier when I set up the permissions, I actually created a situation just like the one you're describing. For the moment, making create and delete only available to the developer effectively allows you to have a one-row settings object that a user can edit but not delete. It's a bit hacky, but it's a solution to go with until I think of something more comprehensive :)

[janhartigan]

Hey @andrewdworn, I just want to let you know that I've added a settings feature in a recent commit (defdea5). You can check out the docs here:

https://github.com/FrozenNode/Laravel-Administrator/blob/3.2.0/docs/settings-configuration.md

The short version is that it works very similar to the model config, except with only the edit_fields property. All field types are allowed with the exception of key and relationship. Instead of taking a firm stance on how to save the data (whether it be by writing to a PHP file, JSON file, or to any combination of SQL tables/rows), I decided to let the system be agnostic about how the developer wants to use the data. For UI purposes, I just store the form data in storage/administrator_settings as a JSON file, but the developer has a beforeSave callback that they can use to manipulate the form data and/or store it however they like. I spent most of yesterday thinking about the best way to approach that problem, but stil the idea is only about a day old. If you have any ideas/suggestion/criticisms, please do let me know.