66 lines
3.2 KiB
Markdown
66 lines
3.2 KiB
Markdown
# Kithkin
|
|
|
|
Contacts and calendars for smart people.
|
|
|
|
## Scheduled jobs
|
|
|
|
Jobs are located in `app/Jobs` and we use Laravel Horizon as an admin frontend.
|
|
|
|
### Starting jobs
|
|
|
|
To start the jobs themselves, run `php artisan schedule:work`. This creates a running process that outputs job runs and other minimal data.
|
|
|
|
#### Production cron
|
|
|
|
On production, this should be setup via cron job like this:
|
|
|
|
```
|
|
* * * * * /usr/bin/php /path/to/artisan schedule:run >> /dev/null 2>&1
|
|
```
|
|
|
|
### Monitoring jobs
|
|
|
|
Horizon is the monitoring app and frontend. Run `php artisan horizon` to start it. This will create a running process that outputs the results of the jobs in a better format than `schedule:work`.
|
|
|
|
The `/horizon` UI is just a normal route in Kithkin; the `php artisan horizon` process is what actually runs the workers and updates Redis for the dashboard.
|
|
|
|
|
|
### Working with scheduled jobs
|
|
|
|
To see the list of scheduled jobs and their crons, run `php artisan schedule:list`.
|
|
|
|
|
|
## Application flow notes for my own sanity
|
|
|
|
### Local calendars
|
|
|
|
#### Local calendar creation
|
|
|
|
Creating a local calendar (not available in the UI yet) hits the `Calendar.php` controller. That `store()` method creates entries in the `calendars`, `calendarinstances`, and `calendar_meta` tables using model functions for each of them.
|
|
|
|
#### Local event creation
|
|
|
|
When the user creates a new event, it gets added to `calendarobjects` where the raw VEVENT data is stored. We have our own utility tables `event_meta` and `locations` for way more metadata and convenience fields so that we don't need to keep parsing the VEVENT blob.
|
|
|
|
The controller is `EventController.php` and it uses models `Event.php` (calendarobjects), `EventMeta.php` (event_meta), and Location.php (locations, not yet created).
|
|
|
|
### Remote calendars
|
|
|
|
Remote calendars are calendars that a user "subscribes" to via .ics URL. These are also called subscription calendars in the app.
|
|
|
|
#### Remote calendar creation
|
|
|
|
The user adds a new remote calendar by entering the url in calendar settings, adding a display name, and picking a color.
|
|
|
|
When a new remote calendar is added, we create a row in `calendarsubscriptions`, `calendars`, and `calendarinstances`, and a corresponding meta data row in `calendar_meta`. This is so verbose because of the way SabreDAV handles remote subscriptions.
|
|
|
|
* Normally, all Sabre does is add a row to `calendarsubscriptions`. It doesn't contemplate pulling the events down into the database locally--it assumes you're fetching the .ics file fresh and parsing out events every time the user loads the calendar.
|
|
|
|
* Since we want to be able to search everything and do more, we need to pull the events down into our database. This requires creating corresponding rows in the local calendar tables. It's a little weird Sabre-wise since we have remote calendars populating their local calendar tables, but Sabre doesn't care that these are in there and it means the user can also share them out again.
|
|
|
|
The controller is `SubscriptionController.php` and it uses the additional model `Subscription.php`.
|
|
|
|
#### Remote events
|
|
|
|
When a user creates an event in a subscription calendar, we need to send that back up to the primary server. We also create the event locally as normal.
|