Add toc to docs

docs/content/doc/development/db-migrations.md

@@ -16,6 +16,8 @@ Additionally, they can also be run directly by using the `migrate` command.
 We use [xormigrate](https://github.com/techknowlogick/xormigrate) to handle migrations, 
 which is based on gormigrate.
 
+{{< table_of_contents >}}
+
 ## Add a new migration
 
 All migrations are stored in `pkg/migrations` and files should have the same name as their id.

docs/content/doc/development/development.md

@@ -17,7 +17,9 @@ If you don't intend to add new dependencies, go `1.9` and above should be fine.
 
 To contribute to Vikunja, fork the project and work on the master branch.
 
-A lot of developing tasks are automated using a Makefile, so make sure to [take a look at it]({{< ref "make.md">}}).
+A lot of developing tasks are automated using a Magefile, so make sure to [take a look at it]({{< ref "mage.md">}}).
+
+{{< table_of_contents >}}
 
 ## Libraries
 
@@ -50,7 +52,7 @@ git remote add origin git@git.kolaente.de:<USERNAME>/api.git
 git fetch --all --prune
 {{< /highlight >}}
 
-This should provide a working development environment for Vikunja. Take a look at the Makefile to get an overview about 
+This should provide a working development environment for Vikunja. Take a look at the Magefile to get an overview about 
 the available tasks. The most common tasks should be `mage test:unit` which will start our test environment and `mage build:build` 
 which will build a vikunja binary into the working directory. Writing test cases is not mandatory to contribute, but it 
 is highly encouraged and helps developers sleep at night.

docs/content/doc/development/mage.md

@@ -15,6 +15,8 @@ Mage is a pure go solution which allows for greater flexibility and things like
 
 This document explains what taks are available and what they do.
 
+{{< table_of_contents >}}
+
 ## Installation
 
 To use mage, you'll need to install the mage cli.

docs/content/doc/development/migration.md

@@ -16,12 +16,14 @@ To make this easier, we have put together a few helpers which are documented on
 In general, each migrator implements a migrator interface which is then called from a client.
 The interface makes it possible to use helper methods which handle http an focus only on the implementation of the migrator itself.
 
-### Structure
+{{< table_of_contents >}}
+
+## Structure
 
 All migrator implementations live in their own package in `pkg/modules/migration/<name-of-the-service>`.
 When creating a new migrator, you should place all related code inside that module.
 
-### Migrator interface
+## Migrator interface
 
 The migrator interface is defined as follows:
 
@@ -41,7 +43,7 @@ type Migrator interface {
 }
 ```
 
-### Defining http routes
+## Defining http routes
 
 Once your migrator implements the migration interface, it becomes possible to use the helper http handlers.
 Their usage is very similar to the [general web handler](https://kolaente.dev/vikunja/web#user-content-defining-routes-using-the-standard-web-handler):
@@ -63,7 +65,7 @@ if config.MigrationWunderlistEnable.GetBool() {
 
 You should also document the routes with [swagger annotations]({{< ref "../practical-instructions/swagger-docs.md" >}}).
 
-### Insertion helper method
+## Insertion helper method
 
 There is a method available in the `migration` package which takes a fully nested Vikunja structure and creates it with all relations. 
 This means you start by adding a namespace, then add lists inside of that namespace, then tasks in the lists and so on.
@@ -81,7 +83,7 @@ if err != nil {
 err = migration.InsertFromStructure(fullVikunjaHierachie, user)
 ```
 
-### Configuration
+## Configuration
 
 You should add at least an option to enable or disable the migration.
 Chances are, you'll need some more options for things like client ID and secret 
@@ -90,7 +92,7 @@ Chances are, you'll need some more options for things like client ID and secret
 The easiest way to implement an on/off switch is to check whether your migration service is enabled or not when 
 registering the routes, and then simply don't registering the routes in the case it is disabled.
 
-#### Making the migrator public in `/info` 
+### Making the migrator public in `/info` 
 
 You should make your migrator available in the `/info` endpoint so that frontends can display options to enable them or not.
 To do this, add an entry to `pkg/routes/api/v1/info.go`.

docs/content/doc/development/structure.md

@@ -45,6 +45,8 @@ In general, this api repo has the following structure:
 
 This document will explain what these mean and what you can find where.
 
+{{< table_of_contents >}}
+
 ## Root level
 
 The root directory is where [the config file]({{< ref "../setup/config.md">}}), [Magefile]({{< ref "mage.md">}}), license, drone config, 

docs/content/doc/development/test.md

@@ -16,24 +16,26 @@ You can run unit tests with [our `Magefile`]({{< ref "mage.md">}}) with
 mage test:unit
 {{< /highlight >}}
 
-### Running tests with config
+{{< table_of_contents >}}
+
+## Running tests with config
 
 You can run tests with all available config variables if you want, enabeling you to run tests for a lot of scenarios.
 
 To use the normal config set the enviroment variable `VIKUNJA_TESTS_USE_CONFIG=1`.
 
-### Show sql queries
+## Show sql queries
 
 When `UNIT_TESTS_VERBOSE=1` is set, all sql queries will be shown when tests are run.
 
-### Fixtures
+## Fixtures
 
 All tests are run against a set of db fixtures.
 These fixtures are defined in `pkg/models/fixtures` in YAML-Files which represent the database structure.
 
 When you add a new test case which requires new database entries to test against, update these files.
 
-# Integration tests
+## Integration tests
 
 All integration tests live in `pkg/integrations`.
 You can run them by executing `mage test:integration`.
@@ -43,7 +45,7 @@ see at the beginning of this document.
 
 To run integration tests, use `mage test:integration`.
 
-# Initializing db fixtures when writing tests
+## Initializing db fixtures when writing tests
 
 All db fixtures for all tests live in the `pkg/db/fixtures/` folder as yaml files.
 Each file has the same name as the table the fixtures are for.