I am asking myself: is there an easy way to change the default settings of the visible columns in the “Settings-Columns-Button”?
Background is: I want some columns be visible by default (which are probably saved within a user account property), but others should not be visible by default. The user should be able to change this setting and it will be saved in his account properties.
Reformulated: is there a way to program, which columns are set/unset in the “Settings-Columns-Dropdown-Menu”?
In summary there is no such feature in Grocery CRUD Enterprise but there is a work-around for this.
More specifically:
Step 1. Use the setUniqueId function to have a unique id for our CRUD so we will use it to cache our visibleColumns in JavaScript
For example:
$crud->setUniqueId('customers_1234');
or for simplicity you can have the table name as the uniqueId:
$crud->setUniqueId('customers');
Step 2. Now write a little JavaScript (yeah I know) to the default columns that you would like to have visible. Just to make it a slightly easier for you, I will write the JavaScript as part of the PHP output. So more specifically:
$tableName = 'customers';
$crud->setTable($tableName);
$crud->setUniqueId($tableName);
// ... some other $crud-> things
$output = $crud->render();
// Make sure that the extra JavaScript code is only applied on Main State
if ($crud->getState() === 'Main') {
$defaultVisibleColumns = function ($uniqueId, $visibleColumns) {
return "<script>
if (!localStorage.getItem('gcrudVisibleColumns_$uniqueId')) {
localStorage.setItem('gcrudVisibleColumns_$uniqueId', '[\"" .
implode('", "', $visibleColumns)
. "\"]');
}
</script>\n";
};
$output->output = $defaultVisibleColumns($tableName, ["customer_name","contact_first_name","notes","email"]) . $output->output;
}
Of course this will be easier to just wait so you can have it as a functionality in Grocery CRUD Enterprise. I understand though that sometimes you just need a work-around as we all have deadlines and bosses so there is your work-around for this
As many people asked for it, It is very possible to be a candidate for the next release.
This is great and I can confirm it works, but needs 1 minor edit if you want unique ids for each instance of a table/form - which I need for my implementation.
The example code
// $output->output = $defaultVisibleColumns($tableName,
["form_name", "table_name", "model_name"]) . $output->output;
// works if you want every GC form with this table to have the same visible columns
$uniqueId = $tableName."_1"; // set a uniqueId, var set is also missing and required in the above sample code
// update the last line of code to use it instead of the $tableName as in the example code)
$output->output = $defaultVisibleColumns(**$uniqueId**,
["form_name", "table_name", "model_name"]) . $output->output;
The other advantage of setting a static unique Id even without the added javascript override is the visibility set by the end user will persist, without hard coding an Id user settings do not persist.
The structure in the storage has changed drastically (as I can see from the browser inspector), so that the JavaScript posted here doesn’t have any effect any more. But I might be able to reengineer to the new structure here, if there’s no easier way already.
The new key for the local storage however has the format persist:<32 hex chars> where setUniqueId() has no influence on the key. How are the <32 hex chars> calculated?
I am really glad that you have asked for. It was the next item on my backlog and I was thinking “Does users still need that?”. I will spend some time and try to have it at the next version.
Meantime, the uniqueId key is the one to use. So if my unique id is ‘customers’ then for this CRUD the local storage will be: persist:customers
if you don’t have set the uniqueId then the key is this:
// Just something to make it unique
$layout->setUniqueId(md5($layout->getApiUrl() . $dbTableName));
but if you are using it like that I strongly recommend adding a setUniqueId instead.
Can I ask you which version you are using by the way?
