Closed jfloPMM closed 5 months ago
@jfloPMM can you give us a better idea of the use case here?
I would expect any report URL you guys attach to a BackgroundCheck record to be a URL back to the Protect My Ministry application. And I would expect that any user who clicks that URL would have to be logged into your application to see the report.
Do you restrict access to the report URL based on login? Assuming the answer is yes, then I expect your customer isn't concerned about who can read the report (since reading the report would require them to log in), but that anyone can see the report URL at all... is that a fair summary?
I don't think we have any plans to add extra permissions around who can see a report URL, but it's also very possible I have misunderstood the issue here.
Hi, The report URL we return to Planning Center opens the pdf to the report. There is no log in required since access to those details can be restricted with Planning Center permissions. However, this use case involves an organization who wants admins to have access to the dates fields but not the report URL.
Jennifer Fowler ministrybrands.comhttp://www.ministrybrands.com/ @.***
From: Tim Morgan @.> Sent: Tuesday, March 12, 2024 4:55 PM To: planningcenter/developers @.> Cc: Jennifer Fowler @.>; Mention @.> Subject: Re: [planningcenter/developers] Question about background check attribute and permissions (Issue #1163)
CAUTION: This is an external email. Please use caution with links and attachments.
@jfloPMMhttps://github.com/jfloPMM can you give us a better idea of the use case here?
I would expect any report URL you guys attach to a BackgroundCheck record to be a URL back to the Protect My Ministry application. And I would expect that any user who clicks that URL would have to be logged into your application to see the report.
Do you restrict access to the report URL based on login? Assuming the answer is yes, then I expect your customer isn't concerned about who can read the report (since reading the report would require them to log in), but that anyone can see the report URL at all... is that a fair summary?
I don't think we have any plans to add extra permissions around who can see a report URL, but it's also very possible I have misunderstood the issue here.
— Reply to this email directly, view it on GitHubhttps://github.com/planningcenter/developers/issues/1163#issuecomment-1992559055, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXVREZT5JJFORSCABI54ZM3YX5TT5AVCNFSM6AAAAABES4SPSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGU2TSMBVGU. You are receiving this because you were mentioned.Message ID: @.**@.>>
Hi @jfloPMM,
We'll keep this use case in mind, but for now, we would definitely recommend the report_url
attribute be used to point to a report screen within your application that is protected by your application's authentication, rather than a downloadable file.
Hi, I had a customer inquire as to whether we could change what we return to the background check attribute field for the 'ReportURL'. We currently return a link to the background check report but she does not want ALL users who have access to the Security Badge more details to be able to view that link. She does want them to know the date the check was run and when it expires. My question is whether this can be restricted by a user permission in Planning Center vs us having to return different values to that field based on the organization set up on the Protect My Ministry side. Will this work differently with any future APIs to your knowledge?
{ "type": "BackgroundCheck", "id": "1", "attributes": { "current": true, "note": "string", "status_updated_at": "2000-01-01T12:00:00Z", "report_url": "string", "expireson": "2000-01-01", **"result": "string",_** "completed_at": "2000-01-01T12:00:00Z" }, "relationships": { "person": { "data": { "type": "Person", "id": "1" } } } }