-
-
Notifications
You must be signed in to change notification settings - Fork 878
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Calendar Access Levels (iOS17+) #1151
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1151 +/- ##
============================================
- Coverage 100.00% 71.42% -28.58%
============================================
Files 1 1
Lines 17 35 +18
============================================
+ Hits 17 25 +8
- Misses 0 10 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution! We are very happy to have you onboard and are impressed by your PR 😄
I have some remarks regarding the architecture. I would appreciate it if you could resolve these issues. If you do not have time/motivation please let us know so we can take over and make sure your works makes it in.
Instead of an add only
permission, we would prefer a full access
permission. This would change the permission approach such that add only
is the default (by requesting Permission.calendar
) and that for full access, you'd need Permission.calendarFullAccess
.
Because there will be two separate permissions for calendar that users of the plugins can use, we do not need extra permission statuses such as 'write only'. Typically, we want to avoid adding more statuses, as this corrodes the experience of our users. In this case, a user that gets 'granted' on Permission.calendar
knows that they have write-only access, so there is no need for additional statuses.
This PR requires changes to all platforms, so the new permission is implemented everywhere. In this case, the new permission on platforms other than iOS can just use the same logic as the current Permission.calendar
, as there is no distinction on those platforms between full access and write-only access. There should be updates to the different platform packages (permission_handler_android
, permission_handler_windows
, permission_handler_web
and permission_handler_linux
). If it is more convenient, we can also make these changes.
/// Events can only be added. If you want to read them as well, use the | ||
/// [calendar] permission instead. | ||
/// iOS: Calendar (17+ read & write access level) | ||
static const calendarAddOnly = Permission._(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We prefer adding new permissions at the end of the list and giving them a higher id, instead of shuffling ids around. While your approach is nicer to the maintainers eye, it is usually a source of bugs because we forget to sync the ids between dart and the platform code. Also, we'd need to update all the platform packages too.
@@ -3,7 +3,7 @@ description: A common platform interface for the permission_handler plugin. | |||
homepage: https://github.com/baseflow/flutter-permission-handler/tree/master/permission_handler_platform_interface | |||
# NOTE: We strongly prefer non-breaking changes, even at the expense of a | |||
# less-clean API. See https://flutter.dev/go/platform-interface-breaking-changes | |||
version: 3.11.5 | |||
version: 3.11.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version: 3.11.6 | |
version: 3.12.0 |
@@ -2,7 +2,7 @@ name: permission_handler_apple | |||
description: Permission plugin for Flutter. This plugin provides the iOS API to request and check permissions. | |||
repository: https://github.com/baseflow/flutter-permission-handler | |||
issue_tracker: https://github.com/Baseflow/flutter-permission-handler/issues | |||
version: 9.1.4 | |||
version: 9.1.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version: 9.1.5 | |
version: 9.2.0 |
@JeroenWeener Thank you for kind words, I've been using your package for a long time so it made sense to give something back. All of requested changes make sense. I have time this week to readjust the PR, but if I run into any issues while adjusting the packages for platforms other then iOS I'll reach out for help. |
@JeroenWeener Does it make sense to mark this in the changelog as a breaking change since requesting calendar now degrades the permission to a write-only, while calendarFullAccess works as calendar used to? |
@MilosKarakas That makes sense 👍 |
Need this update soon! We are pending app store release due to this issue😓 |
@dawsonbristow20 I had a lot of work during last week so I didn't manage to complete this PR, I'm working on this today. |
@JeroenWeener Hi, I think I've adjusted everything as requested, you can review it again when you find time. I wasn't sure only about this part, can you give me an example of what you expect here:
|
@MilosKarakas Thank you for this! |
@parker-sherrill Hey, no problem.. Just make sure to wait until it's reviewed and officially released on pub.dev before using it, I can't guarantee everything is 100% right before @JeroenWeener or someone other who's authorised confirms it. |
Any update on review? @JeroenWeener |
Apologies for the radio silence. We had an internal discussion about splitting read-only and full access calendar permissions. Since Android natively also supports this split, we want to deprecate the |
The platform interface has been updated (see #1181). @MilosKarakas could you update your dependency to There are now three permissions to take into account; This means that the changes in this PR are no longer breaking. If everything went well, you should be able to dismiss your changes to the platform interface. Regarding my earlier comments about updating other platforms, don't worry about it. We will take care of Android and the other platforms. If you have any questions, feel free to hit me up. |
@JeroenWeener Hi, I'll be done with changes by the end of the week, as soon as I catch some time from work. I'll let you know if any questions arise. |
# Conflicts: # permission_handler/CHANGELOG.md # permission_handler/README.md # permission_handler/pubspec.yaml # permission_handler_platform_interface/lib/src/permissions.dart # permission_handler_platform_interface/test/src/permissions_test.dart
One note: I've tested the implementation and when I run the permission_handler_apple Example app on iOS 17.1. And I request calendarWriteOnly. I am unable to request calendarFullAccess. I think it should show something else. Let's see how we can fix this before merging. When I click it i get an error:
Calendar full access does not seem to work. I'll take a look. |
It seems to work correctly, The apple example project was not updated by adding the full access macro's. After I added the Full access macro's it was working as a charm. |
@JeroenWeener Thanks, I hope it gets merged. @TimHoogstrate Thanks for taking a look, I'm glad it works fine. |
Update: last week we merged updates to the different platforms. I just updated this PR which will expose these platform changes. @TimHoogstrate could you provide another review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but i added some comments to make it more in line with other parts of the documentation
Co-authored-by: TimHoogstrate <[email protected]>
Co-authored-by: TimHoogstrate <[email protected]>
@MilosKarakas we merged your PR just now. The new calendar permissions for iOS should be up and running starting with |
@JeroenWeener You're welcome. Thank you and @TimHoogstrate for reviewing and improving the code I submitted, it been a bit back and forth but it's done now. I'm glad I contributed to this great package. |
Fixes #1108.
I don't know if you agree with my approach, I can change it if you have any suggestions.
Pre-launch Checklist
pubspec.yaml
with an appropriate new version according to the pub versioning philosophy, or this PR is does not need version changes.CHANGELOG.md
to add a description of the change.///
).main
.dart format .
and committed any changes.flutter analyze
and fixed any errors.