Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix default values from permission's field presets #10576

Merged
merged 1 commit into from
Dec 25, 2021
Merged

Conversation

azrikahar
Copy link
Contributor

Fixes #10535

Bug

After adding field presets to a particular role to set a default value on create, the default value ended up showing [object Object] instead of testing in this case:

chrome_vszPkMWMC4

chrome_hr3gfjR5fq

Investigation

Seems like it's because the parseFilter here:

if (rawPermission.presets) {
rawPermission.presets = parseFilter(rawPermission.presets);
}

And when it gets set as the default value here:

default_value: permissions.presets![field.field],

It resulted in { _eq: "test" } (hence the [object Object]) instead of "test":

chrome_GkEZ0ojKmr

Solution

Opted to remove the parsing on Presets since I believe they don't need to be parsed? unless there's some misunderstanding on my part. It's also odd how this wasn't brought up before, but it might be some form of unintended regression from the more recent parseFilter change.

After fix applied

chrome_X3FxNGYmkU

@azrikahar azrikahar self-assigned this Dec 21, 2021
@rijkvanzanten rijkvanzanten added this to the v9-next milestone Dec 25, 2021
@rijkvanzanten
Copy link
Member

Opted to remove the parsing on Presets since I believe they don't need to be parsed?

You're absolutely right about this. The presets aren't a filter object, and shouldn't be parsed as such 👍🏻

@HeshamAlassaf
Copy link

Opted to remove the parsing on Presets since I believe they don't need to be parsed?

You're absolutely right about this. The presets aren't a filter object, and shouldn't be parsed as such 👍🏻

What about if I want to use $CURRENT_USER in presets? it doesn't work anymore. Thanks.

@azrikahar
Copy link
Contributor Author

@HeshamAlassaf Would you mind creating an issue to track that? Thanks!

@brandnewx
Copy link

Right now preset on a string field will show up as "eq": "text here" instead of just text here

@azrikahar
Copy link
Contributor Author

@brandnewx By "right now", would you mind to clarify what version of Directus are you on? This fix should be available since v9.4.1. However if you have a minimal reproducible bug report on this presets issue again, and if it's not related to #10782, it'll be very helpful if you can make a new issue for it 👍

@brandnewx
Copy link

brandnewx commented Jan 10, 2022

would you mind to clarify what version of Directus are you on?

Running v9.4.3 docker image using Field Presets on Create role permission. The field shows up text here just fine but after saving, it will be saved as {"_eq":"text here"}

I think you believe it was fixed because it shows up in the editor just fine but the bug is still there. After you save the item and opening it, you'll see the wrong value.

This bug is still reproducible after modifying the field presets and saving it again, to make sure the old saved field presets are replaced by the ones in the new version.

@azrikahar
Copy link
Contributor Author

Thanks for clarifying! That should indeed be the same root cause as #10782.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Field preset not setting the correct value
4 participants