Field Level Visibility and Access Control

[VinayaSathyanarayana]

Question on Field Level Visibility and Edit Control

Suppose I have a set of fields [Sales01, .... Sales31] representing Sales from 1st to 31st of the month
If I want to block users from entering data for selected dates based on some logic, how do I do that?

Sample logic could be:

• In February allow updates till 28th, but block 29,30,31

• Block Updates to certain dates - in case they are Saturday/Sunday/Holiday

Is it possible to specify the access control at the field level to do that

    Sales01: text(
	access: {
        create: false,
        read: true,
        update: () => { (isWorkingDay() )?true:false},
	)

KeystoneJs 5 (not sure about keystone-next) had

   Sales01: {
      type: Text,
      access: {
        read: ({ authentication }) => { 
           ( /* logic */)? return true : return false 
         } 
        update: ({ existingItem, authentication: { item } }) => {
         ( /* logic */)? return true : return false 
        },
      },

Is this functionality going to be available in keystone-next?
Once there is the ability to write a function, the function can be used for the use case I mentioned above.

[timleslie]

You probably want to use a validation hooks.

[VinayaSathyanarayana]

I was able to get it working in keystone-next

• The syntax in keystone-next is different from keystone 5
  Keystone 5 update: ({ existingItem, authentication: { item } }) => {}
  Keystone-next is update: (session) => {}
  Since it was not documented, it took me a lot of time to figure out

IMP - I wish there is a way to get the fieldName to use inside the ui and access functions.
In my current implementation, I am hardcoding the name of the field in a const and using it in the logic of function.

Sales01: {
      type: Text,
      access: {
        read: ({ authentication }) => { 
           const dayOfMonth = 01;   // Note I change this value for every field
           return (( isWorkingDay(dayOfMonth) )? true : false); 
         },
        update: (session)  => {
           const dayOfMonth = 01;   // Note I change this value for every field
           return (( isWorkingDay(dayOfMonth) )? true : false); 
        },
      },
),
// Sales02 to Sales14 come here
Sales15: {
      type: Text,
      access: {
        read: ({ authentication }) => { 
           const dayOfMonth = 15;   // Note I change this value for every field
           return (( isWorkingDay(dayOfMonth) )? true : false); 
         },
        update: (session)  => {
           const dayOfMonth = 15;   // Note I change this value for every field
           return (( isWorkingDay(dayOfMonth) )? true : false); 
        },
      },
),
// Sales16 to Sales31 come here

When there are multiple similar fields, there is lot of code duplication, I wish there is a way to write compact code.

Note: I can help update / refine the documentation, once the outline of keystone-next documentation is ready

[VinayaSathyanarayana]

I am not sure of the syntax for read in keystone-next
read: ({ authentication }) => { }
it may be
read: (session) => { }
Please clarify

[JedWatson]

Hey @VinayaSathyanarayana if you haven't seen them the current drafts for docs on keystone-next are up for preview at https://next.keystonejs.com, you'll see from the PRs we're shipping new docs pretty much daily at this point.

What you want here is to combine the access control functions with the new ui options for fieldMode, which let you set the input to 'hidden' | 'read' | 'edit'.

We still needs docs for that, including how we designed it all to work together, but you can see a good reference implementation in the roles example: https://github.com/keystonejs/keystone/blob/master/examples-next/roles/schema.ts#L33-L68