Closed flochtililoch closed 1 month ago
This is actually not that simple, as CALENDARS_WRITE_ONLY
also exists. If you request it before requesting CALENDARS
, this is possible to escalade from write to read & write. blocked
doesn't work in this case, see:
https://github.com/user-attachments/assets/2827a113-34f2-48b9-8df0-d756bd86b121
But there's indeed an issue. In that case, CALENDARS
should return DENIED
, then BLOCKED
.
I see - if I understand correctly, there's no way to know right now with Apple's APIs whether the in-app prompt to "escalate" from write only to read write is available.
@flochtililoch This is not an issue anymore in v5.0.0. As on Android, it's impossible to know before requesting if the status is DENIED
or BLOCKED
, check
now returns a boolean
(granted, or not).
check(PERMISSIONS.IOS.CALENDARS_WRITE_ONLY)
-> false
request(PERMISSIONS.IOS.CALENDARS_WRITE_ONLY)
-> granted
check(PERMISSIONS.IOS.CALENDARS)
-> false
(write is allowed, read isn't)request(PERMISSIONS.IOS.CALENDARS)
-> granted
Before submitting a new issue
Bug summary
On iOS, I use the
check
method to determine whether or not a specific permission was previously prompted. This gives me the opportunity to render the correct UI to either prompt the permission "in-app" or just redirect to Settings app.When requesting the calendar permission (
PERMISSIONS.IOS.CALENDARS
), the initial in-app prompt let me pick the following two options: "Don't Allow" and "Full Access".I can select either, then go in the Settings app and manually change the permission to "Add Events Only". When I come back into the app, the next call to
check
will return the stringdenied
(enum key:RNPermissionStatusNotDetermined
). However, a subsequent call torequest
will not show the in-app prompt again, I assume because the permission was already prompted / set.I feel like the current handling is incorrect: in this situation the
check
method should returnblocked
(enum key:RNPermissionStatusDenied
). because technically, the calendar permission was already prompted and is no longer requestable in-app. Following the iOS flow chart and this table, the status "denied" implies that the permission is still requestable.Maybe I'm missing something on why this was coded this way, and can certainly build a workaround on my end, but curious whether this should be changed at the library level.
If you agree that this is a bug, I think the change can be as simple as updating this switch case statement to this - I tested it and it yields (what I assume to be) the correct behavior.
Library version
4.1.5
Environment info
Steps to reproduce
check
method - returnsRESULTS.BLOCKED
Reproducible sample code