user createdAt, updatedAt #7
Conversation
affects: @orbiting/backend-modules-auth
… user details affects: @orbiting/backend-modules-auth
| !user || | ||
| (!user.hasPublicProfile && !Roles.userIsMe(user, me)) | ||
| user && | ||
| user.hasPublicProfile || Roles.userIsMeOrInRoles(user, me, ['admin', 'supporter']) |
There was a problem hiding this comment.
wrap this line in parenthesis:
> undefined && undefiend.hasPublicProfile || true
true| @@ -1,8 +1,9 @@ | |||
| const Roles = require('../../lib/Roles') | |||
| const userAccessRoles = ['admin', 'supporter', 'editor'] | |||
There was a problem hiding this comment.
IMO editor should not be a general user access role—just email
| @@ -20,5 +21,13 @@ module.exports = { | |||
| return user.roles | |||
| } | |||
| return [] | |||
| }, | |||
| createdAt (user, args, { user: me }) { | |||
| Roles.ensureUserIsMeOrInRoles(user, me, userAccessRoles) | |||
There was a problem hiding this comment.
For me it's unclear when we should throw based on field level access control. Who will consume createdAt and updatedAt? I can see use cases in the public profile for createdAt. Maybe just make it nullable and return null when not authorised?
There was a problem hiding this comment.
disagree. IMHO the schema should represent reality. Every user has a createdAt and an updatedAt date. I think we should continue to treat access violations with throwing an exception. The client is responsible to only request the appropriate fields, in this case it's the admin tool.
affects: @orbiting/backend-modules-auth
affects: @orbiting/backend-modules-auth
No description provided.