Saleor: Storefront fields in Attribute require admin permissions

[khalibloo]

What I'm trying to achieve

When requesting storefront fields in the graphql Attribute type, such as visibleInStorefront and filterableInStorefront, one requires admin permissions. This should not be the case.

Steps to reproduce the problem

product(id: "sampleID"){
    name
    attributes{
      attribute{
        visibleInStorefront
      }
    }
  }

The query above raises a permission denied error when not logged in.

What I expected to happen

The fields that are relevant to the storefront should be accessible to every user.

System information
Operating system: Windows 10 x64
Browser: Firefox 68

[NyanKiyoshi]

Thanks for the report!

[maarcingebala]

We can make them public but in the storefront, I guess, there shouldn't be a reason to use them. As a storefront API client, you would get only the public ones from API. Plus you have the filtering capabilities in the resolver so you can easily fetch only those that need to be displayed as filters in faceted search.

[khalibloo]

@maarcingebala, thanks for that pointer. I'd been going about attributes in a less straight forward way, I just found.
However, in this particular instance, I need the product's attributes listed on the product page. And only attributes that are marked as visibleInStorefront should show up in the list. It makes sense to use the attributes nested in the Product object as there is no InProduct filter in the attributes resolver.

[petedermott]

If we don't expose these fields to the public API then I wonder what the point of them is?

My initial impression of these values was that they could be used to decide if a variant attribute can be used as non-selectable variant data? For example - you could have a piece of furniture that comes with or without legs, which would affect the height of the unit. You would like to show the difference in height to the end user but you don't want it to be a selectable option on the storefront.

Was this their initial purpose or am I way off base?

[khalibloo]

@petedermott, you're right, it makes sense that they should be used on the product detail page. That is indeed my use case also. And #4673 should allow us to do that.
In other pages however, such as the category page or collection page, and I think that's what @maarcingebala was referring to. It makes more sense to use the filters in the resolver. For example

{
  attributes(inCategory: "my category ID", filter: {filterableInStorefront: true}){
    edges{
      node{
        id
        name
      }
    }
  }
}

[maarcingebala]

Exactly, those fields were implemented as private since they're used in the Dashboard, while storefront users will already get what they need with proper filters. That's why I'm asking what might be the use case for using those fields in public API.

When rendering a product in the public storefront and asking for its attributes you would only get those that an admin configured as visible in the storefront.

[khalibloo]

Thanks for elaborating on that last part. I didn't fully understand it the first time.

Is this the case even even if the logged in user is an admin? Meaning if an admin views the storefront page, will they still get only the attributes configured as visible in storefront? If so, I guess that solves our use cases then.

[maarcingebala]

If you have this query in your storefront:

{
  attributes(first: 5, filter: {visibleInStorefront: true}) {
    edges {
      node {
        name
      }
    }
  }
}

then you would always get only attributes that are meant to be displayed in the storefront, no matter if you're an admin or not.

But if admins sent the same query with visibleInStorefront: false they would get the private attributes. If the unauthenticated clients sent this, they wouldn't get any results since they have no permissions.

[khalibloo]

Thanks, that solves my needs. You may close this if you determine it is not needed.