feat: allow calendar-wide only-availability share setting

[MiragonMx]

Fixes #6247

(Or at least tries do do that)

First shot at implementing the CALDAV:read-free-busy privilege setting.

This should allow sharing a whole calendar with only availability knowledge (without event details) instead of setting this flag for each event individually.

Full disclaimer: this is my first contribution to nextcloud. I don't have much experience with typescript or vue. I've tried my best and have developed my commit based on the PR #6169 . I'm not exactly sure how to test this/if my dev environment that I threw together fully allows for this and I had very lacking network while developing this on public transport.. If there are any pointers/errors/missing things, please point them out or take this over - I only thought I'd kickstart this when I found the referenced issue yesterday and thought this might be a rather minor fix that would benefit me a lot! :)

[SebastianKrupinski]

Hi @MiragonMx

Thank you for the contribution and congratulation on your first contribution!

I will have a closer look at your PR and what you are trying to achieve later this week

[codecov]

Codecov Report

❌ Patch coverage is 10.00000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 13.00%. Comparing base (b3f9102) to head (ea6cc5c).
⚠️ Report is 59 commits behind head on main.

Files with missing lines	Patch %	Lines
src/store/calendars.js	0.00%	5 Missing and 1 partial ⚠️
src/components/AppNavigation/EditCalendarModal.vue	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7556      +/-   ##
==========================================
- Coverage   13.02%   13.00%   -0.02%     
==========================================
  Files         224      224              
  Lines       11634    11653      +19     
  Branches     2797     2814      +17     
==========================================
+ Hits         1515     1516       +1     
- Misses       9759     9776      +17     
- Partials      360      361       +1     

Flag	Coverage Δ
javascript	13.00% <10.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MiragonMx]

As discussed in the related issue (#6247), I suppose I still have to establish the "link" to the existing CalDAV property

CALDAV:read-free-busy Privilege
Calendar users often wish to allow other users to see their busy time
information, without viewing the other details of the calendar
components (e.g., location, summary, attendees). This allows a
significant amount of privacy while still allowing other users to
schedule meetings at times when the user is likely to be free.

I'm not sure, however, where that happens exactly or if my variable name choice would simply have to match the read-free-busy...

[MiragonMx]

Also, I suppose my dev env missed some linters, I'll try to fix that - same for commit signoff

[SebastianKrupinski]

Also, I suppose my dev env missed some linters, I'll try to fix that - same for commit signoff

Linter
npm run lint:fix

DCO
git commit -s --amend > git push --force

[MiragonMx]

Also, I suppose my dev env missed some linters, I'll try to fix that - same for commit signoff

Linter npm run lint:fix

DCO git commit -s --amend > git push --force

Tried at least fixing these obvious blockers, didn't have time to look into it more until now

[SebastianKrupinski]

Hi @MiragonMx

So I looked more in to this. But I have some bad news, the setting you are trying to use (CALDAV:read-free-busy) is an ACL for the Free/Busy view this does not apply to shared calendars. This is not the same as the issue ticket you linked, the ticket talks about shared calendars.

On the PR front, yes the setting is available in the calendar setting modal, but the setting does not get pushed to the server (you can examine the network requests in the browser). To make this work, you need to make the front end push the setting to the server (this might require modification of the nextcloud/cdav-library), then the server code would need to be modified to produce the correct returns when the setting is set.

[MiragonMx]

Hi @SebastianKrupinski , first of all thanks for looking into this and coming back to me so quickly!

So I looked more in to this. But I have some bad news, the setting you are trying to use (CALDAV:read-free-busy) is an ACL for the Free/Busy view this does not apply to shared calendars. This is not the same as the issue ticket you linked, the ticket talks about shared calendars.

Ahh I see. I got the ACL setting from the issue thread (as well as the 'template PR' that I tried to mimic) and thought this would work for shared calendars as well.

On the PR front, yes the setting is available in the calendar setting modal, but the setting does not get pushed to the server (you can examine the network requests in the browser). To make this work, you need to make the front end push the setting to the server (this might require modification of the nextcloud/cdav-library), then the server code would need to be modified to produce the correct returns when the setting is set.

That is what I wondered - I didn't have time to look into the traffic and server side before, but it would have seemed weird to me if this had been enough as I didn't see where I would have changed server side settings - once again, this was mainly based on the other PR on modal transparency, I tried to get this off the ground quickly without digging too deep into the codebase, but this obviously fell short.

What I am unsure about now: do you think that pushing this setting to server side with the corresponding response would be sensible/feasible? And would that still only make this option persistent for regular calendar objects or could that work for shared calendars as well with the server side changes?

I'll try to look into this more soon, it does not surprise me that this does seem to be at least a bit more complex and time consuming than I had initially hoped (though that would have been nice of course :D )...

Thanks again for the feedback and review!

[SebastianKrupinski]

What I am unsure about now: do you think that pushing this setting to server side with the corresponding response would be sensible/feasible? And would that still only make this option persistent for regular calendar objects or could that work for shared calendars as well with the server side changes?

As this setting is meant for the Free/Busy, it would only affect the free busy view.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[MiragonMx]

Hi again, got reminded by the bot... I filled out the form but can't seem to remove the assigned label.
As the PR is in an unfinished state, I've converted it to a draft (should have probably been one too begin with, sry..).
Since I can see now, that this idea won't fix the issue that I tried to solve, I can't prioritize this so much. Thus, I might try to still implement the achievable free-busy-view setting, but I don't know if or when I'll get to that.
I would still keep this PR open as a starting point, but if you deem it more reasonable to close it down and restart whenever it comes up with a clean slate, that would also be fine with me. Just wanted to update on the status from my side, thanks for the quick feedback so far!

[SebastianKrupinski]

@MiragonMx I changed the label for you to developing