Git pull uses a POST request, which is treated as a write request and the CSRF
token is checked. However, no modification to the server is made by git pulls,
as far as I know (actually I'm not sure why it uses a POST). The entire
response is handled by the git command, and the client side is usually the git
command running in the terminal, there's no session and no cookies (as far as I
know). So I'm just disabling CSRF token checking for this route.
The sharer and repo were being taken and used as is to check push permissions,
which is how it's supposed to be, *but* they were also being used as is to
build the repo path! So sharer and repo names that aren't all lowercase were
getting "No such repository" errors when trying to push.
I changed `RepoSpec` to hold `ShrIdent` and `RpIdent` instead of plain `Text`,
to avoid confusions like that and be clear and explicit about the
representation, and failures to find a repo after verifying it against the DB
are now logged as errors to help with debugging.
I hope this fixes the problem.
We have gained:
* Haskell-side validation of schema changes before their execution
* Report of results of migration process
* Handling of old deployments
However:
* The validation code hasn't been tested yet at all
* Most of the migration list hasn't been applied at all yet
* Adding lists of entities from a model file is NOT VALIDATED!!! It's totally
possible to implement, just need to catch all the small details right
Until now the list of DB migration actions was incomplete, containing only
changes made since I added the migration system itself. It now contains the
2016-08-04 model, and then every change made since then.
IMPORTANT: The 2016-08-04 instance doesn't have a schema version entity at all,
so it is assigned version 0, while the actual version of its schema is 1. I'm
going to patch persistent-migration to allow it to be 1, making the migration
path smooth.
A workflow is a new entity in Vervis. It defines the workflow of a
projects' ticket system. That includes the possible ticket states,
custom ticket fields, various filters and so on. All ticket system
customization is currently planned to be managed using workflows.
Currently workflows are private and per sharer, but the plan is to
support public workflows that can be shared and cloned.
If `darcs init` isn't given a `--repodir`, even if you do specify the
new repository's path, it complains that it can't run inside a
repository, because it's running from a darcs clone of Vervis itself. If
the repo dir is specified using `--repodir` instead, Darcs doesn't
complain.
That's at least the situation with 2.8.5, didn't check other versions.
At least in PostgreSQL, at most one reference is allowed. My undirected
recursion code used a UNION of two recursive steps, one for each
direction. That is invalid, so instead I define a CTE that's a union of
the edges and their reverse, and do a single recursion step on that CTE
instead of on the edge table itself.
I thought SQL arrays were common and PersistList corresponded to SQL
array values. But that isn't the case. PersistList seems to be
serialized as a JSON list, and `filterClause` uses IN, not ANY. So I'm
doing the same thing here and using IN.
Note that I'm building the list myself using Text concatenation, not
using `filterClause`, because the latter takes a filter on an existing
`PersistEntity` while my filters often apply to temporary tables.
My implementation in Haskell does work, but ref discovery also includes
capabilities. Since I'm going to use the git binary for the next steps,
I need the git binary to specify here which capabilities it supports.
