Add ical action on MealPlanViewSet to expose filterable ical API in restful manner

[c0mputerguru]

Seems that the django style support for APIs with optional parameters (https://docs.djangoproject.com/en/5.0/topics/http/urls/#specifying-defaults-for-view-arguments) doesn't play nicely with openapi. In particular, it seems that if you use the same function for multiple URLs, they all get the same operation id which has to be unique.

I took a step back and I actually don't like the API design for ical as it isn't really properly formatted as a restful API. Search/filter parameters should generally be query parameters, not part of the URL itself. We already do this for the MealPlan apis; the to/from dates are query parameters for those APIs. I looked and with a bit of refactoring, its actually pretty simple to put the ical API in with the rest of the meal plan APIs, which seems like the more logical place for it to live. Benefit of putting it with the MealPlanViewSet as a new action is that you don't end up with conflicting operation ids. Also, if there are future changes to allow more advanced filtering of meal plans, the ical API gets it all for free.

This time, I made sure to take the extra step of generating the openapi client, and it seems to generate without error. I also took a look at the feature/vue3 branch, and it seems that this way will also work for that, but I didn't actually verify.

I left the original ical API as I wouldn't be surprised if someone somewhere is using it, and didn't want to immediately break them. But we should probably consider deprecating that at some point.

[vabene1111]

Hi, thanks for the fix, this is the proper way I should have implemented this endpoint from the beginning on but back then I did not know about actions.

Generally speaking you are right in assuming that this works in feature/vue3, the only problem is the schema generation has been changed there to DRF spectacular. It would save me a lot of merging trouble if we were to push this change directly against feature/vue3 because I will likely have to merge dev into that multiple times and it would break every time with the schema.

You could just stay on the current version until vue3 is done, I do not plan on making any siginificant changes to the main line in the meantime so you wont miss out on much.

[c0mputerguru]

Ok, makes sense. I've updated the base branch to the vue3 branch for now and updated to use the new drf-spectacular way of describing the schema. Bonus is that way also allows easy customization of the response type for ical which keeps the api documentation and any generated clients accurate.

[c0mputerguru]

Looks like the food shopping tests are currently broken on the feature branch:
django.urls.exceptions.NoReverseMatch: Reverse for 'food-shopping' not found. 'food-shopping' is not a valid view function or pattern name

[vabene1111]

yes but thats not your fault, I broke those but will likely break even more so fixing them later. Thanks for the update, will merge this into the branch when I work on it the next time