#Access Control tab field type

1 messages · Page 1 of 1 (latest)

crimson tusk
#

I just uncovered something I did not expect, I was trying to place access controls on a tab field and while TypeScript allows it (meaning the fields are defined), the controls are not being respected. Can anyone else confirm or does anyone have any info on why this may not be supported?

Willing to file issue if it's needed but wanted to reach out and see if maybe this was by design.

What I'm trying to do:

  {
    // ...
    tabs: [
        {
          label: 'User Info',
          fields: [
  // ...
          ]          
        }, 
        {
          label: 'Access',
          access: {
            read: ({ req }) => {
              return isGlobalAdmin(req.user);
            },
          },
          fields: [
             //...
         }
  // ...
  ]
  // ...
}

My expectation was that for this user, which is not isGlobalAdmin the tab would not be visible.

The isGlobalAdmin has been used elswere on many other fields (and being called as part of other access checks). It's know to be working it is just that a tab field is not respecting the filter.

hollow parcelBOT
subtle iris
#

Can you paste your full tab config

#

If the tab is not named, ie does not have a name property then it is purely a presentational component

#

Meaning the fields you place into it will be considered top-level relative to it

crimson tusk
#

Actually it's too large to fit in discord whichi s why I cut it down to only the parts that matter.

Yes, it's an unnamed tab. Yes, that means that the properties are located on the general type inline with the parent group (field, whatever the parent is).

But that should not prevent Payload from runing the test to test if the tab should be shown at all:

access: {
read: ({ req }) => {
return false;
},
},

Would be another example that I have demonstrated does not work at least on an unnamed tab.

crimson tusk
#

@subtle iris Does this help much? I'm still trying to figure out if this is by design and how I can get passed it because it let's people view stuff that they shouldn't becuase they should have failed auth.

opal wigeon
#

I think if the tab (when unnamed) is just for presentation grouping, then you'd need to add access to each field within that tab. Question is, if all are inaccessible, does the tab no longer appear? Would be good to know.

native jacinth
crimson tusk
#

So if all are inaccessable it will not appear or if all are not accessable it currently still will appear?

native jacinth
crimson tusk
#

Ah, so hiding the entire tab is not supported at this time then.

subtle iris
#

There's a feature PR for conditional tabs on GH right now although I haven't seen much progress on it lately

#

I would suggest moving the access fn's down to the actual fields that need them, or using a group instead

crimson tusk
#

Well yes, that's what I've done, but now I have an empty tab becasue nothing in the tab should be visible if you don't have access. It looks silly because I'm stuck with an empty tab that can't be goten rid of. I can live but it's a bummer that I can't scope out the entire UI for the tab. I'm sure I could create a custom component but I have other priorities right now, and was hoping for more platform support on this item.

native jacinth
crimson tusk
#

I love the idea of the collapsibles as long as they chan have conditional visibility, that would be great, I'll try that out in my next "update to stuff I want to do vs stuff I need to do".

native jacinth
crimson tusk
#

Perfect, thanks for the input, I hadn't had an occasion to try that yet so wouldn't have known.

fallen summit
crimson tusk
#

Can you send me the FR? Maybe (and this is a streatch) when ther priorities allow I can look into what the work would be to make such a change. I just don't have time now as I'm fighting limitations of media and upload file capabilities (for multi-tenant scenarios).