Huge improvements for docs (#58)

docs/content/doc/practical-instructions/database.md

@@ -0,0 +1,38 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Database"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Database
+
+Vikunja uses [xorm](http://xorm.io/) as an abstraction layer to handle the database connection.
+Please refer to [their](http://xorm.io/docs/) documentation on how to exactly use it.
+
+Inside the `models` package, a variable `x` is available which contains a pointer to an instance of `xorm.Engine`.
+This is used whenever you make a call to the database to get or update data.
+
+This xorm instance is set up and initialized every time vikunja is started.
+
+### Adding new database tables
+
+To add a new table to the database, add a an instance of your struct to the `tables` variable in the 
+init function in `pkg/models/models.go`. Xorm will sync them automatically.
+
+You also need to add a pointer to the `tablesWithPointer` slice to enable caching for all instances of this struct.
+
+To learn more about how to configure your struct to create "good" tables, refer to [the xorm documentaion](http://xorm.io/docs/).
+
+### Adding data to test fixtures
+
+Adding data for test fixtures is done in via `yaml` files insinde of `pkg/models/fixtures`.
+
+The name of the yaml file should equal the table name in the database.
+Adding values to it is done via array definition inside of the yaml file.
+
+**Note**: Table and column names need to be in snake_case as that's what is used internally in the database 
+and for mapping values from the database to xorm so your structs can use it.

docs/content/doc/practical-instructions/errors.md

@@ -0,0 +1,72 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Custom Errors"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Custom Errors
+
+All custom errors are defined in `pkg/models/errors.go`.
+You should add new ones in this file.
+
+Custom errors usually have fields for the http return code, a [vikunja-specific error code]({{< ref "../usage/errors.md">}}) 
+and a human-readable error message about what went wrong.
+
+An error consists of multiple functions and definitions:
+
+{{< highlight golang >}}
+// This struct holds any information about this specific error.
+// In this case, it contains the user ID of a nonexistand user.
+// This type should always be a struct, even if it has no values in it.
+
+// ErrUserDoesNotExist represents a "UserDoesNotExist" kind of error.
+type ErrUserDoesNotExist struct {
+	UserID int64
+}
+
+// This function is mostly used in unit tests to check if a returned error is of that type.
+// Every error type should have one of these.
+// The name should always start with IsErr... followed by the name of the error.
+
+// IsErrUserDoesNotExist checks if an error is a ErrUserDoesNotExist.
+func IsErrUserDoesNotExist(err error) bool {
+	_, ok := err.(ErrUserDoesNotExist)
+	return ok
+}
+
+// This is the definition of the actual error type.
+// Your error type is _required_ to implement this in order to be able to be returned as an "error" from functions.
+func (err ErrUserDoesNotExist) Error() string {
+	return fmt.Sprintf("User does not exist [user id: %d]", err.UserID)
+}
+
+// This const holds the vikunja error code used to be able to identify this error without having to 
+// rely on an error string.
+// This needs to be unique, so you should check whether the error code exists or not.
+// The general convention for error codes is as follows:
+// * Every "group" errors lives in a thousend something. For example all user issues are 1000-something, all 
+//   list errors are 3000-something and so on.
+// * New error codes should be the current max error code + 1. Don't take free numbers to prevent old errors
+//   which are depricated and removed from being "new ones". For example, if there are error codes 1001, 1002, 1004,
+//   a new error should be 1005 and not 1003.
+
+// ErrCodeUserDoesNotExist holds the unique world-error code of this error
+const ErrCodeUserDoesNotExist = 1005
+
+// This is the implementation which returns an http error which is then passed to the client.
+// Here you define the http status code with which one the error will be returned, the vikunja error code and 
+// a human-readable error message.
+
+// HTTPError holds the http error description
+func (err ErrUserDoesNotExist) HTTPError() web.HTTPError {
+	return web.HTTPError{
+		HTTPCode: http.StatusNotFound, 
+		Code: ErrCodeUserDoesNotExist, 
+		Message: "The user does not exist.",
+    }
+}
+{{< /highlight >}}

docs/content/doc/practical-instructions/feature.md

@@ -0,0 +1,33 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Add a new api endpoint"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Add a new api endpoint/feature
+
+Most of the api endpoints/features of Vikunja are using the [common web handler](https://code.vikunja.io/web).
+This is a library created by Vikunja in an effort to facilitate the creation of REST endpoints.
+
+This works by abstracting the handling of CRUD-Requests, including rights check.
+
+You can learn more about the web handler on [the project's repo](https://code.vikunja.io/web).
+
+### Helper for pagination
+
+Pagination limits can be calculated with a helper function, `getLimitFromPageIndex(pageIndex)` 
+(only available in the `models` package) from any page number.
+It returns the `limit` (max-length) and `offset` parameters needed for SQL-Queries.
+
+You can feed this function directly into xorm's `Limit`-Function like so:
+
+{{< highlight golang >}}
+lists := []List{}
+err := x.Limit(getLimitFromPageIndex(pageIndex)).Find(&lists)
+{{< /highlight >}}
+
+// TODO: Add a full example from start to finish, like a tutorial on how to create a new endpoint?

docs/content/doc/practical-instructions/mail.md

@@ -0,0 +1,84 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Mailer"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Mailer
+
+This document explains how to use the mailer to send emails and what to do to create a new kind of email to be sent.
+
+## Sending emails
+
+**Note:** You should use mail templates whenever possible (see below).
+
+To send an email, use the function `mail.SendMail(options)`. The options are defined as follows:
+
+{{< highlight golang >}}
+type Opts struct {
+	To          string // The email address of the recipent
+	Subject     string // The subject of the mail
+	Message     string // The plaintext message in the mail
+	HTMLMessage string // The html message 
+	ContentType ContentType // The content type of the mail. Can be either mail.ContentTypePlain, mail.ContentTypeHTML, mail.ContentTypeMultipart. You should set this according to the kind of mail you want to send.
+	Boundary    string
+	Headers     []*header // Other headers to set in the mail.
+}
+{{< /highlight >}}
+
+## Sending emails based on a template
+
+For each mail with a template, there are two email templates: One for plaintext emails, one for html emails.
+
+These are located in the `templates/mail` folder and follow the conventions of `template-name.{plain|hmtl}.tmpl`,
+both the plaintext and html templates are in the same folder.
+
+To send a mail based on a template, use the function `mail.SendMailWithTemplate(to, subject, tpl string, data map[string]interface{})`.
+`to` and `subject` are pretty much self-explanatory, `tpl` is the name of the template, without `.html.tmpl` or `.plain.tmpl`. 
+`data` is a map you can pass additional data to your template.
+
+#### Sending a mail with a template
+
+A basic html email template would look like this:
+
+{{< highlight go-html-template >}}
+{{template "mail-header.tmpl" .}}
+<p>
+    Hey there!<br/>
+    This is a minimal html email example.<br/>
+    {{.Something}}
+</p>
+{{template "mail-footer.tmpl"}}
+{{< /highlight >}}
+
+And the corresponding plaintext template:
+
+{{< highlight go-text-template >}}
+Hey there!
+
+This is a minimal html email example.
+
+{{.Something}}
+{{< /highlight >}}
+You would then call this like so:
+
+{{< highlight golang >}}
+data := make(map[string]interface{})
+data["Something"] = "I am some computed value"
+to := "test@example.com"
+subject := "A simple test mail"
+tpl := "demo" // Assuming you saved the templates as demo.plain.tmpl and demo.html.tmpl
+mail.SendMailWithTemplate(to, subject, tpl, data)
+{{< /highlight >}}
+
+The function does not return an error. If an error occures when sending a mail, it is logged but not returned because sending the mail happens asinchrounly.
+
+Notice the `mail-header.tmpl` and `mail-footer.tmpl` in the template. These populate some basic css, a box for your content and the vikunja logo.
+All that's left for you is to put the content in, which then will appear in a beautifully-styled box.
+
+Remeber, these are email templates. This is different from normal html/css, you cannot use whatever you want (because most of the clients are wayyy to outdated).
+

docs/content/doc/practical-instructions/metrics.md

@@ -0,0 +1,46 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Metrics"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Metrics
+
+Metrics work by exposing a `/metrics` endpoint which can then be accessed by prometheus.
+
+To keep the load on the database minimal, metrics are stored and updated in redis.
+The `metrics` package provides several functions to create and update metrics.
+
+## New metrics
+
+First, define a `const` with the metric key in redis. This is done in `pkg/metrics/metrics.go`.
+
+To expose a new metric, you need to register it in the `init` function inside of the `metrics` package like so:
+
+{{< highlight golang >}}
+// Register total user count metric
+promauto.NewGaugeFunc(prometheus.GaugeOpts{
+    Name: "vikunja_team_count", // The key of the metric. Must be unique.
+    Help: "The total number of teams on this instance", // A description about the metric itself.
+}, func() float64 {
+    count, _ := GetCount(TeamCountKey) // TeamCountKey is the const we defined earlier.
+    return float64(count)
+})
+{{< /highlight >}}
+
+Then you'll need to set the metrics initial value on every startup of vikunja.
+This is done in `pkg/routes/routes.go` to avoid cyclic imports.
+If metrics are enabled, it checks if a redis connection is available and then sets the initial values.
+A convenience function is available if the metric is based on a database struct.
+
+Because metrics are stored in redis, you are responsible to increase or decrease these based on criteria you define.
+To do this, use `metrics.UpdateCount(value, key)` where `value` is the amount you want to cange it (you can pass
+negative values to decrease it) and `key` it the redis key used to define the metric.
+
+# Using it
+
+A Prometheus config with a Grafana template is available at [our git repo](https://git.kolaente.de/vikunja/monitoring).

docs/content/doc/practical-instructions/new-config-options.md

@@ -0,0 +1,31 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Adding new   config options"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Adding new config options
+
+Vikunja uses [viper](https://github.com/spf13/viper) to handle configuration options.
+It handles parsing all different configuration sources.
+
+The configuration is done in sections. These are represented with a `.` in viper.
+Take a look at `pkg/config/config.go` to understand how these are set.
+
+To add a new config option, you should add a default value to `pkg/config/config.go`.
+Default values should always enable the feature to work somehow, or turn it off completely if it always needs
+additional configuration.
+
+Make sure to add the new config option to [the config document]({{< ref "../setup/config.md">}}) and the default config file
+(`config.yml.sample` at the root of the repository) to make sure it is well documented.
+
+If you're using a computed value as a default, make sure to update the sample config file and debian
+post-install scripts to reflect that.
+
+To get a configured option, use `viper.Get("config.option")`.
+Take a look at [viper's documentation](https://github.com/spf13/viper#getting-values-from-viper) to learn of the 
+different ways available to get config options.

docs/content/doc/practical-instructions/swagger-docs.md

@@ -0,0 +1,47 @@
+---
+date: "2019-02-12:00:00+02:00"
+title: "Modifying swagger api docs"
+draft: false
+type: "doc"
+menu:
+  sidebar:
+    parent: "practical instructions"
+---
+
+# Adding/editing swagger api docs
+
+The api documentation is generated using [swaggo](https://github.com/swaggo/swag) from comments.
+
+### Documenting structs
+
+You should always comment every field which will be exposed as a json in the api.
+These comments will show up in the documentation, it'll make it easier for developers using the api.
+
+As an example, this is the definition of a list with all comments:
+
+{{< highlight golang >}}
+// List represents a list of tasks
+type List struct {
+	// The unique, numeric id of this list.
+	ID int64 `xorm:"int(11) autoincr not null unique pk" json:"id" param:"list"`
+	// The title of the list. You'll see this in the namespace overview.
+	Title string `xorm:"varchar(250)" json:"title" valid:"required,runelength(3|250)" minLength:"3" maxLength:"250"`
+	// The description of the list.
+	Description string `xorm:"varchar(1000)" json:"description" valid:"runelength(0|1000)" maxLength:"1000"`
+	OwnerID     int64  `xorm:"int(11) INDEX" json:"-"`
+	NamespaceID int64  `xorm:"int(11) INDEX" json:"-" param:"namespace"`
+
+	// The user who created this list.
+	Owner User `xorm:"-" json:"owner" valid:"-"`
+	// An array of tasks which belong to the list.
+	Tasks []*ListTask `xorm:"-" json:"tasks"`
+
+	// A unix timestamp when this list was created. You cannot change this value.
+	Created int64 `xorm:"created" json:"created"`
+	// A unix timestamp when this list was last updated. You cannot change this value.
+	Updated int64 `xorm:"updated" json:"updated"`
+
+	web.CRUDable `xorm:"-" json:"-"`
+	web.Rights   `xorm:"-" json:"-"`
+}
+{{< /highlight >}}