forge/Vervis
1
0
Fork 0
Code Pull requests Activity
Vervis/config/models

458 lines
9.7 KiB
Text
Raw Normal View History

Move some files around, tweak the generated code a bit
2016-02-14 10:10:21 +01:00
-- This file is part of Vervis.
--
Rename project field in Project Role assignment tables, it had the wrong name
2019-01-26 13:56:15 +01:00
-- Written in 2016, 2018, 2019 by fr33domlover <fr33domlover@riseup.net>.
Move some files around, tweak the generated code a bit
2016-02-14 10:10:21 +01:00
--
-- ♡ Copying is an act of love. Please copy, reuse and share.
--
-- The author(s) have dedicated all copyright and related and neighboring
-- rights to this software to the public domain worldwide. This software is
-- distributed without any warranty.
--
-- You should have received a copy of the CC0 Public Domain Dedication along
-- with this software. If not, see
-- <http://creativecommons.org/publicdomain/zero/1.0/>.
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
-------------------------------------------------------------------------------
-- Instances
-------------------------------------------------------------------------------
Instance
host Host
UniqueInstance host
DB: Add RemoteObject entity and use it in RemoteActivity instead of iid+lu
2019-11-05 05:08:36 +01:00
RemoteObject
instance InstanceId
ident LocalURI
UniqueRemoteObject instance ident
Rename PersonInGroup model to GroupMember
2016-05-24 10:28:57 +02:00
-------------------------------------------------------------------------------
-- People
-------------------------------------------------------------------------------
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Sharer
New sharer field: Creation time
2016-05-24 10:34:40 +02:00
ident ShrIdent
name Text Maybe
Remove the last remaining default= from models file Since defaults are specified in Form code that inserts new entities, they already appear on the application side. So I'm going to try managing them *only* in the application, and not have defaults in the DB at all (maybe just temporarily when needed for schema migrations).
2016-08-20 19:32:27 +02:00
created UTCTime
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Finish route change, it builds now I used this chance to make some name changes, add some utils, tweak some imports, remove more `setTitle`s and so on. I also made person, repo, key and project creation forms verify CI-uniqueness.
2016-05-23 22:46:54 +02:00
UniqueSharer ident
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Person
Email tokens expire within 1 day
2018-04-01 05:02:35 +02:00
ident SharerId
login Text
passphraseHash ByteString
email EmailAddress
verified Bool
verifiedKey Text
verifiedKeyCreated UTCTime
resetPassKey Text
resetPassKeyCreated UTCTime
Add "about" field to person table, display in person page
2019-01-27 00:39:13 +01:00
about Text
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
inbox InboxId
Decouple OutboxItem from Person via a new table named Outbox
2019-06-15 20:51:26 +02:00
outbox OutboxId
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
followers FollowerSetId
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
UniquePersonIdent ident
UniquePersonLogin login
Allow login using email address
2018-04-11 13:09:42 +02:00
UniquePersonEmail email
Add UniquePersonInbox to persistent model; each user has their own unique inbox
2019-06-09 17:56:42 +02:00
UniquePersonInbox inbox
Decouple OutboxItem from Person via a new table named Outbox
2019-06-15 20:51:26 +02:00
UniquePersonOutbox outbox
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
UniquePersonFollowers followers
Decouple OutboxItem from Person via a new table named Outbox
2019-06-15 20:51:26 +02:00
Outbox
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Create Note outbox handler, not in use yet I wrote a function handleOutboxNote that's supposed to do the whole outbox POST handler process. There's an outbox item table in the DB now, I adapted things in various source files. Ticket comment federation work is still in progress.
2019-03-28 22:08:30 +01:00
OutboxItem
Decouple OutboxItem from Person via a new table named Outbox
2019-06-15 20:51:26 +02:00
outbox OutboxId
Switch OutboxItem's Activity from plain BL to an upgraded PersistJSONObject
2019-06-29 05:19:00 +02:00
activity PersistJSONObject
Create Note outbox handler, not in use yet I wrote a function handleOutboxNote that's supposed to do the whole outbox POST handler process. There's an outbox item table in the DB now, I adapted things in various source files. Ticket comment federation work is still in progress.
2019-03-28 22:08:30 +01:00
published UTCTime
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
Inbox
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
InboxItem
Implement basic notifications in DB and UI
2019-05-22 23:50:30 +02:00
unread Bool
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
Unfinished updated outbox handler
2019-04-11 15:44:44 +02:00
InboxItemLocal
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
inbox InboxId
Unfinished updated outbox handler
2019-04-11 15:44:44 +02:00
activity OutboxItemId
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
item InboxItemId
Unfinished updated outbox handler
2019-04-11 15:44:44 +02:00
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
UniqueInboxItemLocal inbox activity
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
UniqueInboxItemLocalItem item
Unfinished updated outbox handler
2019-04-11 15:44:44 +02:00
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
RemoteActivity
DB: Add RemoteObject entity and use it in RemoteActivity instead of iid+lu
2019-11-05 05:08:36 +01:00
ident RemoteObjectId
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
content PersistJSONObject
received UTCTime
DB: Add RemoteObject entity and use it in RemoteActivity instead of iid+lu
2019-11-05 05:08:36 +01:00
UniqueRemoteActivity ident
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
InboxItemRemote
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
inbox InboxId
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
activity RemoteActivityId
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
item InboxItemId
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
Add an Inbox table in DB, make inbox related tables use it instead of Person This allows the inbox system to be separate from Person, allowing other kinds of objects to have inboxes too. Much like there's FollowerSet which works separately from Tickets, and will allow to have follower sets for projects, users, etc. too. Inboxes are made independent from Person users because I'm going to give Projects inboxes too.
2019-06-09 15:16:32 +02:00
UniqueInboxItemRemote inbox activity
Implement GETing the personal inbox
2019-05-05 12:20:55 +02:00
UniqueInboxItemRemoteItem item
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
UnlinkedDelivery
Remember for deliveries in the DB, whether they should sign forwarding
2019-05-02 11:31:56 +02:00
recipient UnfetchedRemoteActorId
activity OutboxItemId
forwarding Bool
running Bool
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
UniqueUnlinkedDelivery recipient activity
Delivery
Remember for deliveries in the DB, whether they should sign forwarding
2019-05-02 11:31:56 +02:00
recipient RemoteActorId
activity OutboxItemId
forwarding Bool
running Bool
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
UniqueDelivery recipient activity
Do inbox forwarding in project inbox handler
2019-05-03 23:04:53 +02:00
Forwarding
recipient RemoteActorId
activity RemoteActivityId
activityRaw ByteString
sender ProjectId
signature ByteString
running Bool
UniqueForwarding recipient activity
Store remote actor keys in the DB, reuse them instead of GETing every time
2019-02-03 14:58:14 +01:00
VerifKey
New Network.FedURI with separate URI modes for dev and for fediverse FedURIs, until now, have been requiring HTTPS, and no port number, and DNS internet domain names. This works just fine on the forge fediverse, but it makes local dev builds much less useful. This patch introduces URI types that have a type tag specifying one of 2 modes: - `Dev`: Works with URIs like `http://localhost:3000/s/fr33` - `Fed`: Works with URIs like `https://dev.community/s/fr33` This should allow even to run multiple federating instances for development, without needing TLS or reverse proxies or editing the hosts files or anything like that.
2019-07-23 15:59:48 +02:00
ident LocalRefURI
Support for instance-scope keys when verifying HTTP signature
2019-02-06 03:48:23 +01:00
instance InstanceId
expires UTCTime Maybe
HTTP Signature verification: RSA-SHA256 and PEM/ASN1 support Before, things worked like this: * Only signatures of Ed25519 keys could be verified * Key encoding placed the plain binary Ed25519 key in the PEM, instead of the key's ASN1 encoding With this patch it now works like this: * Ed25519 signatures are supported as before * RSA keys are now supported too, assuming RSA-SHA256 signatures * Both Ed25519 and RSA keys are encoded and decoded using actual PEM with ASN1
2019-03-11 00:15:42 +01:00
public PublicVerifKey
Rename RemoteSharer entity to RemoteActor
2019-04-12 02:56:27 +02:00
sharer RemoteActorId Maybe
Store remote actor keys in the DB, reuse them instead of GETing every time
2019-02-03 14:58:14 +01:00
Add LocalURI type for recording shared URI host
2019-02-22 00:59:53 +01:00
UniqueVerifKey instance ident
Store remote actor keys in the DB, reuse them instead of GETing every time
2019-02-03 14:58:14 +01:00
Record usage of instance keys in the DB When we verify an HTTP signature, * If we know the key, check in the DB whether we know the actor lists it. If it doesn't, and there's room left for keys, HTTP GET the actor and update the DB accordingly. * If we know the key but had to update it, do the same, check usage in DB and update DB if needed * If we don't know the key, record usage in DB However, * If we're GETing a key and discovering it's a shared key, we GET the actor to verify it lists the key. When we don't know the key at all yet, that's fine (can be further optimized but it's marginal), but if it's a key we do know, it means we already know the actor and for now it's enough for us to rely only on the DB to test usage.
2019-02-19 11:54:55 +01:00
VerifKeySharedUsage
key VerifKeyId
Rename RemoteSharer entity to RemoteActor
2019-04-12 02:56:27 +02:00
user RemoteActorId
Record usage of instance keys in the DB When we verify an HTTP signature, * If we know the key, check in the DB whether we know the actor lists it. If it doesn't, and there's room left for keys, HTTP GET the actor and update the DB accordingly. * If we know the key but had to update it, do the same, check usage in DB and update DB if needed * If we don't know the key, record usage in DB However, * If we're GETing a key and discovering it's a shared key, we GET the actor to verify it lists the key. When we don't know the key at all yet, that's fine (can be further optimized but it's marginal), but if it's a key we do know, it means we already know the actor and for now it's enough for us to rely only on the DB to test usage.
2019-02-19 11:54:55 +01:00
UniqueVerifKeySharedUsage key user
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
UnfetchedRemoteActor
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
ident RemoteObjectId
since UTCTime Maybe
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
UniqueUnfetchedRemoteActor ident
Implement outbox remote delivery, in handler and periodic, not used yet
2019-04-16 16:27:50 +02:00
Rename RemoteSharer entity to RemoteActor
2019-04-12 02:56:27 +02:00
RemoteActor
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
ident RemoteObjectId
Store names of remote actors in DB for display
2019-05-21 10:44:11 +02:00
name Text Maybe
Add field errorSince to RemoteActor to track inbox POST unreachability
2019-04-12 03:09:45 +02:00
inbox LocalURI
errorSince UTCTime Maybe
Support remote actors specifying 2 keys, and DB storage of these keys It's now possible for activities we be attributed to actors that have more than one key. We allow up to 2 keys. We also store in the DB. Scaling to support any number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and because 2 is the actual number we need. By having 2 keys, and replacing only one of them in each rotation, we avoid race conditions. With 1 key, the following can happen: 1. We send an activity to another server 2. We rotate our key 3. The server reaches the activity in its processing queue, tries to verify our request signature, but fails because it can't fetch the key. It's the old key and we discarded it already, replaced it with the new one When we use 2 keys, the previous key remains available and other servers have time to finish processing our requests signed with that key. We can safely rotate, without worrying about whether the user sent anything right before the rotation time. Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe because it's optional, but it's just Vervis right now. Once Vervis itself starts using 2 keys, it will be able to rotate freely without race condition risk, but probably Mastodon etc. won't accept its signatures because of the use of 2 keys and because they're server-scope keys. Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
UniqueRemoteActor ident
Support for instance-scope keys when verifying HTTP signature
2019-02-06 03:48:23 +01:00
Smarter treatment of recipients that are collections - Allow client to specify recipients that don't need to be delivered to - When fetching recipient, recognize collections and don't try to deliver to them - Remember collections in DB, and use that to skip HTTP delivery
2019-05-18 00:42:01 +02:00
RemoteCollection
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
ident RemoteObjectId
Smarter treatment of recipients that are collections - Allow client to specify recipients that don't need to be delivered to - When fetching recipient, recognize collections and don't try to deliver to them - Remember collections in DB, and use that to skip HTTP delivery
2019-05-18 00:42:01 +02:00
DB: Use RemoteObject in UnfetchedRemoteActor, RemoteActor, RemoteCollection
2019-11-06 20:47:50 +01:00
UniqueRemoteCollection ident
Smarter treatment of recipients that are collections - Allow client to specify recipients that don't need to be delivered to - When fetching recipient, recognize collections and don't try to deliver to them - Remember collections in DB, and use that to skip HTTP delivery
2019-05-18 00:42:01 +02:00
Implement remote following, disable automatic following This patch contains migrations that require that there are no follow records. If you have any, the migration will (hopefully) fail and you'll need to manually delete any follow records you have. In the next patch I'll try to add automatic following on the pseudo-client side by running both e.g. createNoteC and followC in the same POST request handler.
2019-09-25 12:43:05 +02:00
FollowRemoteRequest
person PersonId
target FedURI
recip FedURI Maybe
public Bool
activity OutboxItemId
UniqueFollowRemoteRequest person target
UniqueFollowRemoteRequestActivity activity
FollowRemote
person PersonId
recip RemoteActorId -- actor managing the followed object
target FedURI -- the followed object
public Bool
follow OutboxItemId
accept RemoteActivityId
UniqueFollowRemote person target
UniqueFollowRemoteFollow follow
UniqueFollowRemoteAccept accept
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
FollowerSet
Follow
person PersonId
target FollowerSetId
Specify visibility in Follow records
2019-09-09 02:33:36 +02:00
public Bool
Implement remote following, disable automatic following This patch contains migrations that require that there are no follow records. If you have any, the migration will (hopefully) fail and you'll need to manually delete any follow records you have. In the next patch I'll try to add automatic following on the pseudo-client side by running both e.g. createNoteC and followC in the same POST request handler.
2019-09-25 12:43:05 +02:00
follow OutboxItemId
accept OutboxItemId
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
UniqueFollow person target
Implement remote following, disable automatic following This patch contains migrations that require that there are no follow records. If you have any, the migration will (hopefully) fail and you'll need to manually delete any follow records you have. In the next patch I'll try to add automatic following on the pseudo-client side by running both e.g. createNoteC and followC in the same POST request handler.
2019-09-25 12:43:05 +02:00
UniqueFollowFollow follow
UniqueFollowAccept accept
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
RemoteFollow
Rename RemoteSharer entity to RemoteActor
2019-04-12 02:56:27 +02:00
actor RemoteActorId
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
target FollowerSetId
Specify visibility in Follow records
2019-09-09 02:33:36 +02:00
public Bool
Implement remote following, disable automatic following This patch contains migrations that require that there are no follow records. If you have any, the migration will (hopefully) fail and you'll need to manually delete any follow records you have. In the next patch I'll try to add automatic following on the pseudo-client side by running both e.g. createNoteC and followC in the same POST request handler.
2019-09-25 12:43:05 +02:00
follow RemoteActivityId
accept OutboxItemId
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
UniqueRemoteFollow actor target
Implement remote following, disable automatic following This patch contains migrations that require that there are no follow records. If you have any, the migration will (hopefully) fail and you'll need to manually delete any follow records you have. In the next patch I'll try to add automatic following on the pseudo-client side by running both e.g. createNoteC and followC in the same POST request handler.
2019-09-25 12:43:05 +02:00
UniqueRemoteFollowFollow follow
UniqueRemoteFollowAccept accept
Make the DB migrations not depend on current model
2019-04-11 15:26:57 +02:00
Implement DB-based SSH authentication
2016-03-06 12:58:48 +01:00
SshKey
Finish route change, it builds now I used this chance to make some name changes, add some utils, tweak some imports, remove more `setTitle`s and so on. I also made person, repo, key and project creation forms verify CI-uniqueness.
2016-05-23 22:46:54 +02:00
ident KyIdent
Implement DB-based SSH authentication
2016-03-06 12:58:48 +01:00
person PersonId
algo ByteString
content ByteString
Finish route change, it builds now I used this chance to make some name changes, add some utils, tweak some imports, remove more `setTitle`s and so on. I also made person, repo, key and project creation forms verify CI-uniqueness.
2016-05-23 22:46:54 +02:00
UniqueSshKey person ident
Implement DB-based SSH authentication
2016-03-06 12:58:48 +01:00
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Group
ident SharerId
Rename PersonInGroup model to GroupMember
2016-05-24 10:28:57 +02:00
UniqueGroup ident
GroupMember
person PersonId
group GroupId
Add group roles and make a group's creator its admin
2016-05-25 17:52:15 +02:00
role GroupRole
Enable adding group members
2016-05-26 18:25:23 +02:00
joined UTCTime
Rename PersonInGroup model to GroupMember
2016-05-24 10:28:57 +02:00
UniqueGroupMember person group
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
Role
Add project roles, basically a copy of the repo role code
2016-06-01 10:52:14 +02:00
ident RlIdent
Roles now under by sharers, i.e. now groups too
2016-06-06 19:29:54 +02:00
sharer SharerId
Add project roles, basically a copy of the repo role code
2016-06-01 10:52:14 +02:00
desc Text
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
UniqueRole sharer ident
Add project roles, basically a copy of the repo role code
2016-06-01 10:52:14 +02:00
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
RoleInherit
parent RoleId
child RoleId
Build role graph
2016-06-21 09:35:19 +02:00
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
UniqueRoleInherit parent child
Build role graph
2016-06-21 09:35:19 +02:00
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
RoleAccess
role RoleId
Add project roles, basically a copy of the repo role code
2016-06-01 10:52:14 +02:00
op ProjectOperation
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
UniqueRoleAccess role op
Add project roles, basically a copy of the repo role code
2016-06-01 10:52:14 +02:00
Rename PersonInGroup model to GroupMember
2016-05-24 10:28:57 +02:00
-------------------------------------------------------------------------------
-- Projects
-------------------------------------------------------------------------------
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Project
Finish route change, it builds now I used this chance to make some name changes, add some utils, tweak some imports, remove more `setTitle`s and so on. I also made person, repo, key and project creation forms verify CI-uniqueness.
2016-05-23 22:46:54 +02:00
ident PrjIdent
Add Ticket to persistent model
2016-04-30 22:40:33 +02:00
sharer SharerId
Default roles for repos and turn user/anon collab tables into proj/repo fields * Repo collab now supports basic default roles developer/user/guest like project collab does * User/Anon collab for repos and projects are now stored as fields instead of in dedicated tables, there was never a need for dedicated tables but I didn't see that before * Repo push op is now part of `ProjectOperation` * `RepoRole` and related code has been entirely removed, only project roles remain and they're used for both repos and projects * This is the first not-totally-trivial DB migration in Vervis, it's automatic but please be careful and report errors
2019-01-29 23:24:32 +01:00
name Text Maybe
desc Text Maybe
Projects must specify a ticket workflow
2016-08-08 21:05:22 +02:00
workflow WorkflowId
Remove some default column values from model, leave that to Haskell
2016-08-08 20:35:01 +02:00
nextTicket Int
Default roles for repos and turn user/anon collab tables into proj/repo fields * Repo collab now supports basic default roles developer/user/guest like project collab does * User/Anon collab for repos and projects are now stored as fields instead of in dedicated tables, there was never a need for dedicated tables but I didn't see that before * Repo push op is now part of `ProjectOperation` * `RepoRole` and related code has been entirely removed, only project roles remain and they're used for both repos and projects * This is the first not-totally-trivial DB migration in Vervis, it's automatic but please be careful and report errors
2019-01-29 23:24:32 +01:00
wiki RepoId Maybe
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
collabUser RoleId Maybe
collabAnon RoleId Maybe
Give each project an inbox in DB
2019-06-09 18:21:23 +02:00
inbox InboxId
Give Project an Outbox in the DB
2019-06-16 23:34:06 +02:00
outbox OutboxId
Project team and followers * Have a project team collection, content is the same as ticket team (but potentially ticket team allows people to opt out of updates on specific tickets, while project team isn't tied to any specific ticket or other child object) * Have a project followers collection, and address it in ticket comments in addition to the already used recipients (project, ticket team, ticket followers)
2019-06-11 14:19:51 +02:00
followers FollowerSetId
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
UniqueProject ident sharer
Give each project an inbox in DB
2019-06-09 18:21:23 +02:00
UniqueProjectInbox inbox
Give Project an Outbox in the DB
2019-06-16 23:34:06 +02:00
UniqueProjectOutbox outbox
Project team and followers * Have a project team collection, content is the same as ticket team (but potentially ticket team allows people to opt out of updates on specific tickets, while project team isn't tied to any specific ticket or other child object) * Have a project followers collection, and address it in ticket comments in addition to the already used recipients (project, ticket team, ticket followers)
2019-06-11 14:19:51 +02:00
UniqueProjectFollowers followers
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Repo
Finish route change, it builds now I used this chance to make some name changes, add some utils, tweak some imports, remove more `setTitle`s and so on. I also made person, repo, key and project creation forms verify CI-uniqueness.
2016-05-23 22:46:54 +02:00
ident RpIdent
Repos right under users, not under projects
2016-04-12 19:37:31 +02:00
sharer SharerId
Remove some default column values from model, leave that to Haskell
2016-08-08 20:35:01 +02:00
vcs VersionControlSystem
Repos specify their VCS (i.e. Git or Darcs) in the DB
2016-05-03 01:51:53 +02:00
project ProjectId Maybe
desc Text Maybe
Remove some default column values from model, leave that to Haskell
2016-08-08 20:35:01 +02:00
mainBranch Text
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
collabUser RoleId Maybe
collabAnon RoleId Maybe
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
inbox InboxId
Implement C2S Follow activity and add form on /publish page
2019-09-11 10:12:20 +02:00
outbox OutboxId
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
followers FollowerSetId
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Repos right under users, not under projects
2016-04-12 19:37:31 +02:00
UniqueRepo ident sharer
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
UniqueRepoInbox inbox
Implement C2S Follow activity and add form on /publish page
2019-09-11 10:12:20 +02:00
UniqueRepoOutbox outbox
Handle post-receive hook, publish a Push activity
2019-09-09 02:27:45 +02:00
UniqueRepoFollowers followers
Make initial homepage with table and simple login
2016-02-16 12:41:13 +01:00
Per-sharer ticket workflows 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.
2016-08-08 13:05:19 +02:00
Workflow
sharer SharerId
ident WflIdent
name Text Maybe
desc Text Maybe
Workflow scope field, minimal support
2016-09-01 19:40:02 +02:00
scope WorkflowScope
Per-sharer ticket workflows 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.
2016-08-08 13:05:19 +02:00
UniqueWorkflow sharer ident
Per-workflow custom ticket fields
2016-08-08 16:01:06 +02:00
WorkflowField
Custom ticket field relevance filter by ticket status
2016-08-11 11:27:30 +02:00
workflow WorkflowId
ident FldIdent
name Text
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
desc Text Maybe
Custom ticket field relevance filter by ticket status
2016-08-11 11:27:30 +02:00
type WorkflowFieldType
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
enm WorkflowEnumId Maybe
Custom ticket field relevance filter by ticket status
2016-08-11 11:27:30 +02:00
required Bool
constant Bool
filterNew Bool
filterTodo Bool
filterClosed Bool
Very basic support for ticket label colors - WorkflowField now has a color, it's a simple `Maybe Int` for now. Valid values are only 1-4 - That color is used for displaying ticket class params a.k.a labels in ticket list view - Ticket list now also serves a paged OrderedCollection I tried to use a single SQL query to grab the tickets along with their labels, but couldn't figure out a way to aggregate tuples/rows into an array (it seems only single values are supported in Esqueleto). Instead of doing manual SQL or adding Esqueleto functions, I just switched from 1 query to O(n) queries: Each ticket has its own query selecting its labels. I guess it's slower, but also, ticket list is paged now with fixed page size so it's really O(1) ^_^
2020-01-16 11:29:47 +01:00
color Int Maybe
Per-workflow custom ticket fields
2016-08-08 16:01:06 +02:00
UniqueWorkflowField workflow ident
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
WorkflowEnum
Per-workflow custom ticket field enum types
2016-08-08 16:48:38 +02:00
workflow WorkflowId
ident EnmIdent
name Text
desc Text Maybe
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
UniqueWorkflowEnum workflow ident
Per-workflow custom ticket field enum types
2016-08-08 16:48:38 +02:00
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
WorkflowEnumCtor
enum WorkflowEnumId
Field enums aren't useful if you can't define values
2016-08-08 19:05:09 +02:00
name Text
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
desc Text Maybe
Field enums aren't useful if you can't define values
2016-08-08 19:05:09 +02:00
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
UniqueWorkflowEnumCtor enum name
Field enums aren't useful if you can't define values
2016-08-08 19:05:09 +02:00
Display custom ticket field values in ticket page
2016-08-08 22:51:58 +02:00
TicketParamText
ticket TicketId
field WorkflowFieldId
value Text
UniqueTicketParamText ticket field
Display custom enum fields in ticket page
2016-08-09 13:36:14 +02:00
TicketParamEnum
ticket TicketId
field WorkflowFieldId
DB: Rename entity WorkflowFieldEnum to WorkflowEnum
2020-01-05 13:04:17 +01:00
value WorkflowEnumCtorId
Display custom enum fields in ticket page
2016-08-09 13:36:14 +02:00
UniqueTicketParamEnum ticket field value
Implement ticket class params
2020-01-05 15:33:10 +01:00
TicketParamClass
ticket TicketId
field WorkflowFieldId
UniqueTicketParamClass ticket field
Add Ticket to persistent model
2016-04-30 22:40:33 +02:00
Ticket
Stop assigning ticket numbers, allow them to be NULL
2020-02-03 16:44:16 +01:00
number Int Maybe
Add ticketDescription DB entity field, containing pandoc-rendered HTML
2019-06-03 14:45:02 +02:00
created UTCTime
Handle Offer{Ticket} in project inbox, and turn DB ticketTitle into HTML
2019-06-17 21:55:03 +02:00
title Text -- HTML
Add ticketDescription DB entity field, containing pandoc-rendered HTML
2019-06-03 14:45:02 +02:00
source Text -- Pandoc Markdown
description Text -- HTML
assignee PersonId Maybe
status TicketStatus
closed UTCTime
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
closer PersonId Maybe
Add Ticket to persistent model
2016-04-30 22:40:33 +02:00
Stop assigning ticket numbers, allow them to be NULL
2020-02-03 16:44:16 +01:00
-- UniqueTicket project number
Compressed inventory parser and DarcsRev TH utils
2016-05-17 22:34:22 +02:00
DB: Add LocalTicket table This is a step preparing for the Create flow for tickets. Each Ticket now gets a matching LocalTicket that points to it. But otherwise the LocalTicket isn't in use yet.
2020-02-05 13:08:39 +01:00
LocalTicket
ticket TicketId
discuss DiscussionId
followers FollowerSetId
UniqueLocalTicket ticket
UniqueLocalTicketDiscussion discuss
UniqueLocalTicketFollowers followers
DB: Add TicketProjectLocal table, pointing to Ticket but not in use yet
2020-02-06 05:18:19 +01:00
TicketProjectLocal
ticket TicketId
project ProjectId
accept OutboxItemId
UniqueTicketProjectLocal ticket
UniqueTicketProjectLocalAccept accept
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
TicketAuthorLocal
DB: Remove foreign key from TicketAuthorLocal to Ticket, not needed anymore Since TicketAuthorLocal now points to LocalTicket, which in turn points to Ticket.
2020-02-06 04:41:16 +01:00
ticket LocalTicketId
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
author PersonId
DB: In TAL and TAR, rename 'offer' to 'open' That's because with the Create flow added, the activity that reports a ticket can be either Create or Offer, maybe later Announce too. The old TAL unique name mentioned in the migration has what may look like a typo, "Locale" instead of "Local". That's because I made a typo in migration 115, and now needed to specify the typoed name I used then. I verified in dev DB and on dev.angeley.es DB that the typo is reflected in the PostgreSQL database side and fixed by the new migrations.
2020-02-08 10:35:35 +01:00
open OutboxItemId
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
DB: In TAL and TAR, rename 'offer' to 'open' That's because with the Create flow added, the activity that reports a ticket can be either Create or Offer, maybe later Announce too. The old TAL unique name mentioned in the migration has what may look like a typo, "Locale" instead of "Local". That's because I made a typo in migration 115, and now needed to specify the typoed name I used then. I verified in dev DB and on dev.angeley.es DB that the typo is reflected in the PostgreSQL database side and fixed by the new migrations.
2020-02-08 10:35:35 +01:00
UniqueTicketAuthorLocal ticket
UniqueTicketAuthorLocalOpen open
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
TicketAuthorRemote
DB: Remove unnecessary fkey from TicketAuthorRemote to Ticket Since it points to TicketProjectLocal which in turn points to Ticket.
2020-02-08 00:05:42 +01:00
ticket TicketProjectLocalId
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
author RemoteActorId
DB: In TAL and TAR, rename 'offer' to 'open' That's because with the Create flow added, the activity that reports a ticket can be either Create or Offer, maybe later Announce too. The old TAL unique name mentioned in the migration has what may look like a typo, "Locale" instead of "Local". That's because I made a typo in migration 115, and now needed to specify the typoed name I used then. I verified in dev DB and on dev.angeley.es DB that the typo is reflected in the PostgreSQL database side and fixed by the new migrations.
2020-02-08 10:35:35 +01:00
open RemoteActivityId
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
DB: In TAL and TAR, rename 'offer' to 'open' That's because with the Create flow added, the activity that reports a ticket can be either Create or Offer, maybe later Announce too. The old TAL unique name mentioned in the migration has what may look like a typo, "Locale" instead of "Local". That's because I made a typo in migration 115, and now needed to specify the typoed name I used then. I verified in dev DB and on dev.angeley.es DB that the typo is reflected in the PostgreSQL database side and fixed by the new migrations.
2020-02-08 10:35:35 +01:00
UniqueTicketAuthorRemote ticket
UniqueTicketAuthorRemoteOpen open
Allow ticket author to be a remote actor
2019-06-07 06:26:32 +02:00
Ticket dependencies in DB and per-ticket list of children
2016-06-07 22:16:15 +02:00
TicketDependency
Implement getTicketDepR, not used anywhere else yet This patch also disables the ability to specify deps when creating a ticket, because those deps won't be in the ticket object anymore. Instead of coding a workaround and getting complications later, I just disabled that thing. It wasn't really being used by anyone anyway.
2019-07-11 17:14:16 +02:00
parent TicketId
child TicketId
author PersonId
summary Text -- HTML
created UTCTime
Ticket dependencies in DB and per-ticket list of children
2016-06-07 22:16:15 +02:00
UniqueTicketDependency parent child
Ticket claim requests in DB and personal list view of them
2016-06-07 12:01:57 +02:00
TicketClaimRequest
person PersonId
ticket TicketId
Per-ticket list of claim requests with full info
2016-06-07 18:31:55 +02:00
message Text -- Assume this is Pandoc Markdown
Ticket claim requests in DB and personal list view of them
2016-06-07 12:01:57 +02:00
created UTCTime
UniqueTicketClaimRequest person ticket
Compressed inventory parser and DarcsRev TH utils
2016-05-17 22:34:22 +02:00
Discussion
Add route getMessageR, returns an Activity Note for any locally created Message
2019-03-22 21:46:42 +01:00
RemoteDiscussion
DB: Switch RemoteDiscussion to use RemoteObject instead of instance+ident
2020-02-08 11:55:19 +01:00
ident RemoteObjectId
discuss DiscussionId
Add route getMessageR, returns an Activity Note for any locally created Message
2019-03-22 21:46:42 +01:00
DB: Switch RemoteDiscussion to use RemoteObject instead of instance+ident
2020-02-08 11:55:19 +01:00
UniqueRemoteDiscussionIdent ident
UniqueRemoteDiscussion discuss
Add route getMessageR, returns an Activity Note for any locally created Message
2019-03-22 21:46:42 +01:00
Compressed inventory parser and DarcsRev TH utils
2016-05-17 22:34:22 +02:00
Message
created UTCTime
Rename messageContent field to messageSource; content will soon be HTML
2019-06-02 14:04:35 +02:00
source Text -- Pandoc Markdown
Render in advance and store comment content as HTML alongside Markdown source
2019-06-02 16:41:51 +02:00
content Text -- HTML
Compressed inventory parser and DarcsRev TH utils
2016-05-17 22:34:22 +02:00
parent MessageId Maybe
root DiscussionId
List collab tables under projects section in models file
2019-02-12 12:46:12 +01:00
In ticket comment tree, support mixing local and remote (federated) comments
2019-03-20 09:07:37 +01:00
LocalMessage
Create Note outbox handler, not in use yet I wrote a function handleOutboxNote that's supposed to do the whole outbox POST handler process. There's an outbox item table in the DB now, I adapted things in various source files. Ticket comment federation work is still in progress.
2019-03-28 22:08:30 +01:00
author PersonId
rest MessageId
Add field localMessageCreate, pointing to the OutboxItem that created it I added a migration that creates an ugly fake OutboxItem for messages that don't have one. I'll try to turn it into a real one. And then very possibly remove the whole ugly migration, replacing it with addFielfRefRequiredEmpty, which should work for empty instances.
2019-05-25 05:23:57 +02:00
create OutboxItemId
Create Note outbox handler, not in use yet I wrote a function handleOutboxNote that's supposed to do the whole outbox POST handler process. There's an outbox item table in the DB now, I adapted things in various source files. Ticket comment federation work is still in progress.
2019-03-28 22:08:30 +01:00
unlinkedParent FedURI Maybe
In ticket comment tree, support mixing local and remote (federated) comments
2019-03-20 09:07:37 +01:00
UniqueLocalMessage rest
Add unique UniqueLocalMessageCreate
2019-05-25 14:59:54 +02:00
UniqueLocalMessageCreate create
In ticket comment tree, support mixing local and remote (federated) comments
2019-03-20 09:07:37 +01:00
RemoteMessage
Rename RemoteSharer entity to RemoteActor
2019-04-12 02:56:27 +02:00
author RemoteActorId
Receive remote comments on local ticket discussion
2019-03-21 23:57:15 +01:00
instance InstanceId
ident LocalURI
rest MessageId
Implement sharer inbox handler It runs checks against all the relevant tables, but ultimately just inserts the activity into the recipient's inbox and nothing more, leaving the RemoteMessage creation and inbox forwarding to the project inbox handler.
2019-04-23 04:57:53 +02:00
create RemoteActivityId
Add route getMessageR, returns an Activity Note for any locally created Message
2019-03-22 21:46:42 +01:00
lostParent FedURI Maybe
Receive remote comments on local ticket discussion
2019-03-21 23:57:15 +01:00
UniqueRemoteMessageIdent instance ident
In ticket comment tree, support mixing local and remote (federated) comments
2019-03-20 09:07:37 +01:00
UniqueRemoteMessage rest
(Hopefully correctly) fill project inboxes with ticket comment Create Notes
2019-06-09 20:41:37 +02:00
UniqueRemoteMessageCreate create
In ticket comment tree, support mixing local and remote (federated) comments
2019-03-20 09:07:37 +01:00
List collab tables under projects section in models file
2019-02-12 12:46:12 +01:00
RepoCollab
repo RepoId
person PersonId
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
role RoleId Maybe
List collab tables under projects section in models file
2019-02-12 12:46:12 +01:00
UniqueRepoCollab repo person
ProjectCollab
project ProjectId
person PersonId
Rename role related tables to reflect the role unification There used to be project roles and repo roles, and they were separate. A while ago I merged them, and there has been a single role system, used with both repos and projects. However the table names were still "ProjectRole" and things like that. This patch renames some tables to just refer to a "Role" because there's only one kind of role system.
2019-05-31 17:02:57 +02:00
role RoleId Maybe
List collab tables under projects section in models file
2019-02-12 12:46:12 +01:00
UniqueProjectCollab project person
Copy permalink