Creating a constituent with code-level security active - and not being able to see it once it's made

Dev Lunsford · May 2021

Hi, when we create a new constituent with a user that has constituent code-level security (only allow certain codes) - we create the constituent and then immediately can't see it to give it a code. I can't see how to add a code on creation of a constituent, is this possible? It means that our only choice is to give these users access to the whole database. Has anyone else seen this?

It's actually a bit of a GDPR issue because users of our member registration app are able to see a lot more than we'd like them to. It's not feasible to filter the search results they see either because you can't filter a search call based on a const code, and making a call to list const codes on each member returned in a search and then filtering that way is much too intensive. At the moment we're having to obscure search results and add additional code to prevent the wrong records from being loaded, but all this would be saved if we could make a single call to add a constituent with a const code supplied on creation.

We also can't restrict down in the opposite way (do not allow access to these codes) because there aren't codes that can easily be added to all DB records other than the ones we need to see here, and making sure that every new record in the rest of the DB gets this 'exclude' code will be impossible.

Heather MacKenzie · May 2021

Giving it the code isn't available during creation?

Dev Lunsford · May 2021

Unfortunately not, it would be useful to at least add a primary code even if it can't let you add more than one. I hope they add it somehow.

https://developer.sky.blackbaud.com/docs/services/56b76470069a0509c8f1c5b3/operations/CreateConstituent

As soon as you add it, it becomes a constituent that you can't see.

Ben Lambert · May 2021

Hi,

This is good feedback about being able to include a constituent code when creating a constituent record - I'll make sure that request is routed to the appropriate team here at Blackbaud.

I'd like to better understand the problem you're having though...based on what you've described, this isn't an API-only issue right? If that same user (who has permission to create constituents) logs into NXT and uses the UX to create a constituent, is that constituent immediately inaccessible? In other words, the API behavior you're seeing should match the behavior that user sees in the UI, right?

Any more details you can provide (be as explicit as possible) would be helpful just to make sure we fully understand the problem.

Thanks!

Dev Lunsford · May 2021

Hi Ben, thanks for the reply. The NXT interface for creating a new constituent has a place to add codes during the creation process, so while it's possible to create a constituent that you then can't see again, it's also possible to get it right if you're paying attention :-)

So in a way, this is an API-only issue. I'm getting some of this second-hand from our developer, but our app users currently have to have no code-level security because this was an issue early on - he reported creating constituents and immediately being unable to reference them until we opened it up. It might be possible for me to test the app using a test user that does have code security on, and see what happens... Or I could use the test framework pages I suppose. I'm not really a developer though, although I do our Power Automate flows and know a little bit about using other APIs in that, so should be able to have a go :-)

To best describe the problem:

Using the Constituent POST, there is no option to add a constituent code during the call that creates the constituent. We complete that in a second API call once the constituent exists - we use the returned ID to then add codes and other details to the new constituent. With constituent-code-level security set in database view for those users, because the new constituent had no codes, it did not fall into the scope of allowed records for the app/user to see, and so the second and subsequent calls to add codes and so on failed as that record could not be found by that user.

In the app this means that people can see records that are unrelated to the service we are providing - the volunteers using the app end up searching for themselves for fun and then seeing their contact details come up, they are concerned that this shouldn't happen.

Currently we're having to come up with other ways to get around this, and one idea that was suggested was to create our own middle-man API that would capture our call to create a constituent, create it using a different user that had the rights to see more, and then pass back to the original user and API to finish the job. To me, that sounds more complicated than adding the ability to add a code during creation...!

I guess this is kind of a niche issue, but I hope it makes it to the drawing board :-) Let me know if you want any more information about this, and thanks again for passing it on.

Dev

Ben Lambert · May 2021

Thanks for the additional info - this definitely helps explain the problem.

The in-product UI for creating a constituent has really grown to include more functionality than what is available via the public API endpoint. I've routed this feedback to the team that owns this functionality, and will report back with any new developments. Thanks again for bringing this to our attention!

Dev Lunsford · May 2021

Thanks. I'm wishing I had reported it straight away and gained a few months of head start getting it to you :-( but at that time I wasn't really engaged in the community. Glad this is helpful to you. I'll keep an eye out and if this makes it to production I will learn to do a backflip. OK, probably not. But I will be gleefully happy at the very least :-)

Creating a constituent with code-level security active - and not being able to see it once it's made

Comments

Categories