Conditional readonly fields

[MtDalPizzol]

Hi, folks! It's been a week since I dived deep into learning Statamic and I'd like to share a situation I dealt with that a I find could maybe be better handled by the framework. Maybe there's already a better way of doing this, but I couldn't find it on the dos nor the discussions. It goes like this:

I have 2 roles: editor and writer
I have a schedule blueprint with the following fields:

• title
• contents
• deadline
• priority

An editor can edit everything.
An writer, however, can view everything, but cannot edit deadline and priority.

So, I started thinking how could I achieve this.

First try

My first try was to add two priority fields to the blueprint and conditionally switch between them based on the user role. The editor field would have it's visibility set to visible while the writer field would be set to readonly. I quickly found out that you can't have 2 fields with the same handle in a blueprint.

Getting the correct UI

Then, I kept the basic idea but, for the writer, instead of the readonly fields, I created a computed_priority and a computed_deadline, set their visibility to computed and used the same display label for them as the ones for the editor. This way I got visually identical forms for both roles, but preventing writer users from being able to change priority and deadline.

The form submission problem

From there, the problem became this: when a writer submits the form, since priority and deadline aren't included in the payload because these are computed, they end up overriding the already saved entry's priority and deadline. For instance:

If an editor saved this:

{
   "title": "My editor shcedule title",
   "priority": "high",
   "deadline":"2023-01-08",
   "contents": "My editor created content"
}

And then a writer submitted the form, the entry's data ended up like this:

{
   "title": "My writer edited shcedule title",
   "priority": null,
   "deadline": null,
   "contents": "My writer edited content"
}

So, I needed a way to prevent writer users from touching this properties.

Is event subscribers the best choice for this?

So, I created an event subscriber to listen for the EntrySaving event. In there, I check the role of the user submitting the form, and then use the current saved data to set the missing payload values on the entry being saved. Here's a simplified version of the subscriber:

<?php

namespace App\Listeners;

use Statamic\Events\EntrySaving;

class EntrySubscriber
{
   public function saving($event) {
      if (!User::current()->hasRole('writer')) {
         return;
      }

      $event->entry->set('priority', $event->entry->model()->data['priority']);
      $event->entry->set('deadline', $event->entry->model()->data['deadline']);
   }

   public function subscribe($events)   {
      return [
         EntrySaving::class => 'saving'
      ];
   }
}

This is working perfectly as I intended. I just think it's a bit cumbersome. Is there a better/easier way to achieve this?
If there isn't, we could think of alternatives to make this kind of scenario easier to deal with.

What could be done?

The first thing that comes to my mind is to have an option on the collection to tell Statamic not to touch saved values if their not present on the request. Something that worked like array_replace_recursive, keeping everything form the source and replacing existing keys.

Again... I don't know the internals of Statamic and even if this is possible. But I think something like this could make things a lot easier in several scenarios. What do you think?

[edalzell]

You could make custom fields?

[MtDalPizzol]

Yes, I could. But regardless of the solution I decide to adopt. My point is that this is unexpected behavior. I'm not sure, but I'm using the eloquent driver, and maybe this is something related to that, since I didn't see anyone else talking about this.

For instance:

In the same form I have a Slug field. On the database, this field has it's own slug column, it's not under the data column, like the other fields.

If I hide the Slug field from writer users and add sometimes to the validation, when a writer submits the form, the payload doesn't contain the slug and the slug column remains untouched in the database. This is the expected behavior when something isn't present in the payload. Not to nuke whatever is already in the database. But, for every field saved under the data column, anything missing from the payload vanishes.

If this is not related to the eloquent driver, and it's something that Statamic can't change at the core level, we could at least receive the current saved value at the field handle on the process method so we can return it when there's nothing on the payload. This way, those who think this should be the default behavior can extend the base Fieldtype class or something like that to return the already saved value.

[twd3]

Wouldn't this addon work? https://statamic.com/addons/thoughtco/restrict-fields

[MtDalPizzol]

@twd3 That's not the problem. I'm able to conditionally show fields based on user roles. That's pretty basic stuff. The problem is that when the fields are hidden, they are overriding the values saved by other users when fields are visible.

I'm not sure, but if I had to guess, I would say this is a bug with the statamic/eloquent-driver, that simply shoves the resulting data of the blueprint handling into the data column on the database.

What I did now was to replace the save method on the EntryRepository class of the eloquent driver, simply filtering the resulting data from the blueprint handling, removing the keys that aren't in the request payload and merging the filtered array with the data in the database.

    public function save($entry)
    {
        // Data resulting from the blueprint handling
        $processedData = $entry->data();

        // Get the keys from the payload
        $payloadKeys = array_keys(request()->all());

        // Remove keys that aren't in the payload from the processed data
        $updates = $processedData->only($payloadKeys)->all();

        // Curent data in the datababe
        $storedData = $entry->model()->data;

        // Merge new values into current data
        $newData = array_replace_recursive([], $storedData, $updates);

        // Update the entry instance data with the new data
        $entry->data($newData);

        $model = $entry->toModel();

        $model->save();

        $entry->model($model->fresh());

        Blink::put("eloquent-entry-{$entry->id()}", $entry);
        Blink::put("eloquent-entry-{$entry->uri()}", $entry);
    }

I hope this makes the problem clearer. I'm still not sure if this is a bug or the expected behavior, and I also don't know if this is something happening only when using a database. Either way, if anyone think it's a bug, I'm glad to open an issue or a PR.