Changed name dinsdag kring and remove woensdag kring

[lodewiges]

required for csvalpha/amber-ui#885, they depend on eachother

fixes #437

merging this PR has a high risk off breaking all icalender links

still needs testing, this needs to be done on staging

note to self: most likely migration needs to be updated

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.92%. Comparing base (1bfe253) to head (e5cf8ff).

Additional details and impacted files

@@           Coverage Diff            @@
##           staging     #438   +/-   ##
========================================
  Coverage    99.92%   99.92%           
========================================
  Files          203      203           
  Lines         2714     2714           
========================================
  Hits          2712     2712           
  Misses           2        2           

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

[lodewiges]

This PR will need to be merged at the same time the accompanying pr on amber/ui is getting merged. I could also be writen in such a way that there is no need for this however this requires 2 PR and manual changing all activities instead of using a migration

[DrumsnChocolate]

I think you need to write csvalpha/amber-ui#876 rather than https://github.com/csvalpha/amber-ui/#876

but on top of that, you probably meant csvalpha/amber-ui#885 instead.

merging this PR has a high risk off breaking all icalender links

That sounds like a not so amazing outcome if that happens. I have not taken the time to determine how the ical links work, so I will postpone reviewing this PR until I have the time and energy to figure that out

[lodewiges]

I think you need to write csvalpha/amber-ui#876 rather than https://github.com/csvalpha/amber-ui/#876

but on top of that, you probably meant csvalpha/amber-ui#885 instead.

merging this PR has a high risk off breaking all icalender links

That sounds like a not so amazing outcome if that happens. I have not taken the time to determine how the ical links work, so I will postpone reviewing this PR until I have the time and energy to figure that out

https://csvalpha.nl/ical/activities?key=privatestuff&user_id=1&categories=algemeen,societeit,vorming,dinsdagkring,woensdagkring,choose,ifes,ozon,disputen,kiemgroepen,huizen,extern,eerstejaars,curiositates

This is an example link from icalender feature on the site you can see the "dinsdagkring,woensdagkring" part of the link, this will be replaced by "kring" with this PR. This is because the names in the link correspond with the names your able to select. This is why most likely all links are going to break.

I personally think that we should notify all members in advance and update it.

[lodewiges]

I think you need to write csvalpha/amber-ui#876 rather than https://github.com/csvalpha/amber-ui/#876

but on top of that, you probably meant csvalpha/amber-ui#885 instead.

merging this PR has a high risk off breaking all icalender links

That sounds like a not so amazing outcome if that happens. I have not taken the time to determine how the ical links work, so I will postpone reviewing this PR until I have the time and energy to figure that out

bump?

[lodewiges]

okay, so i did some more research this will not break all links, if people dont update the link. the only affect is that kring doesnt showup anymore

[DrumsnChocolate]

I personally think that we should notify all members in advance and update it.

I agree.

okay, so i did some more research this will not break all links, if people dont update the link. the only affect is that kring doesnt showup anymore

That's good to hear. But it's still important to notify people.

This whole thing makes me wonder: is there an easy way to prevent people from having to update their ical links everytime we change a category? Ideally, we would have a situation where we give the user a single link, https://csvalpha.nl/ical/activities?key=privatestuff&user_id=1
And then based on user_id we identify the user and then simply query their calendar settings from our database. We would need to add a place to store this information, but I think it would be much neater since we would never have to ask a user to update their ical links again!

[DrumsnChocolate]

we would never have to ask a user to update their ical links again!

In fact, we would even be able to leave the current ical links as they are; simply ignore the categories parameter and only use the user_id

[lodewiges]

you are correct it would be the best option, i think we should made a issue so we can do this in the future

[DrumsnChocolate]

you are correct it would be the best option, i think we should made a issue so we can do this in the future

made one: #483