Return a user's Permission Strings


As a developer, I'd like to be able to make one RESTful call about a User in the Reference Data service to get a list of Permission Strings so that I can use these strings within my own service in determining what a User may and may not do.

For background on what a Permission String is read this.

Acceptance Criteria:

  • Create a RESTful endpoint named GET /api/users/{id}/permissionStrings

  • Require an AccessToken, return a 401 if the token isn't a system token or is the user specific in the URI.

  • Return a JSON array of strings. Each element in the array should be unique. The strings are of the form:

    • DirectRoleAssignment: rightUUID

    • FulfillmentRoleAssignment: rightUUID-facilityUUID

    • SupervisoryRoleAssignment: rightUUID-facilityUUID-programUUID (note one supervisory role assignment may result in many strings as the assignment will have to be recursed down)

  • add to RAML with a description that this resource of PermissionStrings is based on

  • when a User's role assignment(s) change, what's returned by this GET operation should change

  • support Etags in the header of the GET response. Additionally support the HEAD operation, returning the same headers as the GET response.

    • the etag of course could be used by the client, if the client sends the same etag, return a 304 Not Modified

  • should return this list of permission strings in less than 0.5 second for the administrator user in demo data for 90% of users (p90)


Chongsun Ahn
July 20, 2017, 8:30 PM

Per discussion with Josh, we'll be using a pipe (|) as a delimiter between UUIDs/names instead of a dash , since UUIDs have a dash in them.

Josh Zamor
July 29, 2017, 3:43 AM

: I think we need to re-open this. We discussed how to seed demo data, but then I think we got distracted and forgot:

Either a DB migration or some sort of initializer (like audit log initializer)

Chongsun Ahn
July 31, 2017, 4:05 PM

I agree about needing to think about migrating production data. However, I can't see how the error in the contract test is related to the changes. That looks like a 403 error from processingPeriods endpoint? Possibly from an incorrect access token?

Josh Zamor
July 31, 2017, 5:35 PM

it's related in that I changed checkAdminRight to use the permission strings for performance, and saw some great improvements, however contract tests setup roles and rights outside of demo data. So it's related, I'm not sure if the fix here will solve how contract tests work, however we at least need to migrate/maintain production data here.

Josh Zamor
August 15, 2017, 7:06 AM

This looks good, I'm not sure how this would be QAed in a useful fashion so I'm going to move it to done.



Chongsun Ahn


Josh Zamor

Story Points





Fix versions