Crud: [Proposal/Suggestion/Enhancement] addField method 'view/update/create/all' (readonly and/or disabled fields)

[giovannipds]

Hello! I was playing with Backpack CRUD and apparently there's no way of showing fields in the administration panel without allowing edition, something like a readonly/disabled, am I wrong?!

If there really isn't, maybe the addField method can change to something like 'view/update/create/all', and if there's only view and not update, we can show the field with a readonly/disabled.

Concerns? If I am wrong, please let me know.

[indra1]

What you mean is that when you edit you want to have some fields disabled? While there is currently no such feature you can create your own custom fields that do just that. Just add yourfield.blade.php to resources/views/vendor/backpack/crud/fields

[AurelDragut]

i think @giovannipds needs a field that is available only on the create process and, either if he makes a new field type just like you said, @indra1, he will need to add some sort of condition (if it's the edit page those fields get the 'disabled' attribute).

[indra1]

@giovannipds I remembered there should be a feature for update/create/both
It should look somehting like this:
$this->crud->addField(
[
'name' => 'field_text',
'type' => 'text',
'label' => 'field_label',
], 'create'); // and for options you have create and update , when nothing is chosen both is assumed

Check Backpack\CRUD\PanelTraits\Fields for code.

[giovannipds]

What I meant is, I would like to have some data(fields) displayed on the update page, without allowing the user to change those fields, just to see/read them (like a readonly field, or a disabled input).

If I just mark it with create, I won't be able to see that field when updating an entry. Right?

Anyway, creating custom fields is awesome! Is there a way to check if I'm on the update or if I'm on the create page? As @AurelDragut mentioned.

Thanks guys!

[indra1]

@giovannipds
If I just mark it with create, I won't be able to see that field when updating an entry. Right? yes

To check if you're on edit page (there's where the update is triggered from):
do something like if(isset($entry->id))

the edit page is effectively edit.blade.php if you want to check it out and if you are in the newly custom form just check if the field has a value isset($field['value'])

[giovannipds]

Awesome! Thanks @indra1!!

The proposal of this issue was to enable support of readonly fields on the update page somehow, but if you guys don't think that's relevant (because we can have custom fields anyway), please just feel free to close the issue.

Regards.

[indra1]

@giovannipds I think we should leave it open for now. It would be a good feature

[AurelDragut]

@giovannipds, this feature doesn't seem to be quite useful (you are the first one that i see talking about this feature), though you can see those "read only" fields at any time just by viewing instead of editing that model record.

If you really wanna do something like this, the best way i think it is to add an additional attribute in the field definition for this feature and in blade templates of the fields that might need this add a condition if the added attribute has "true" value and if it meets the condition you can add to it a 'disabled=disabled' html attribute. something like:

<input type='file' <?=(($field['attribute']==true)?'disabled=disabled':'')?> ... />

[giovannipds]

@indra1 @AurelDragut I'm on up to you guys. I agree with @indra1. Thanks @AurelDragut. =)

[AurelDragut]

Another thing i can't test now it's a security issue: i think that if you show disabled fields in the form they might be modified by a web developer tool like Firebug, so on update the values might get changed beside that 'disabled' attribute...(i remember i tested something like this quite a time ago on a lesson about form validation).

[indra1]

That's true, but if you remove the name of the field it should not work, but a smart person might still be able to bypass that easily. Let me get back to you on this.

[tabacitu]

@giovannipds ,

We've had a solution for this use case from day 1. disabled and readonly are just some attributes you need to push on the <input>. Right? So you can do this:

$this->crud->addField([ // Text
    'name' => 'title',
    'label' => "Title",
    'type' => 'text',
], 'create');
$this->crud->addField([ // Text
    'name' => 'title',
    'label' => "Title",
    'type' => 'text',
    'attributes' => ['readonly' => 'readonly'],
], 'update');

This will show a normal field on CREATE and a readonly field on UPDATE.

Please note:

• with the readonly attribute, when Saved it will still send the string to be saved; yes, it might be a security issue, but we're talking admin panel here, we trust the admins not to be hackers;
• with the disabled attribute, when Saved it will NOT send the string; so it will most likely clear the value in your database, unless you create a mutator on your model to specify otherwise;
• the attributes will work for most field types, but I don't think it will work for complicated ones (ex: table);

Cheers!

P.S. I'll go ahead and close this issue so we don't clog the section. Feel free to open it again if you encounter problems or comment if you have follow-ups.

[giovannipds]

@tabacitu Damnn! Never thought about that this way, I guess I was too concerned on not duplicating addField method. Indead, your approach may work as expected. Thank you very much for sharing it with us. Cheers to everyone!

[joshlewis]

Googled for a read-only field approach and found this. Just wanted to go on record that @giovannipds isn't the only person who would like something built-in.

In my case, it's an auto-generated field (think of it like a special token or key associated with the record) that I only want to show after creation, and never allow manually updating.

Anyway, thanks! :)

[tabacitu]

Hi @joshlewis ,

I think the disabled attribute is perfect for you, then!

$this->crud->addField([ // Text
    'name' => 'title',
    'label' => "Title",
    'type' => 'text',
    'attributes' => ['disabled' => 'disabled'],
], 'update');

[SonicZentropy]

Also googled for the same feature and ended up here. The 'disabled' and 'readonly' attributes ARE what I needed, so thanks! Perhaps a quick mention of these somewhere in the Field Types documentation would be appropriate?

[indra1]

@SonicZentropy will do, but you can also edit it yourself and @tabacitu then reviews it.

[axelzuzek]

Are there any news on this topic? I would need to implement user access control at field level. "Invisible / Read-Only / Write" on a field, depending on a certain permission of the current user. The solution above 'attributes' => [disabled...... 'update') doesn't prevent simple post hacking.

[indra1]

@axelzuzek No as far as I know, but if you want you could overwrite the store method and remove those fields from the request as needed for now.

[axelzuzek]

@indra1 thx, it works for me. for simple attributes it is enough to remove the "read-only" attribute from request to avoid overwriting with empty values ($request->remove("readonlyattributename"). For many2many relationships this seems not to be enough. In addition I had to set dynamically 'pivot' => false in the addField options. I think the syncPivot in the create and update traits should only be called if there are request parameters present?

[axelzuzek]

Here is an example for the archive:

if ($perm->mayRead("users")) {
            $template = $perm->mayUpdate("users") ? "select2_multiple" : "select2_multiple_readonly";
            $this->crud->addField([      
                'label' => "Users",
                'type' => $template,
                'name' => 'users', 
                'entity' => 'users', 
                'attribute' => 'name',
                'model' => "App\Models\User", 
                'pivot' =>  $perm->mayUpdate("users"), 
            ]);
        }
...
// pseudocode
 public function update(UpdateRequest $request)
        foreach ($this->getAllReadonlyAttributesAsArray() as $attribute) {
            $request->request->remove($attribute);
        }