How to do a replicated bug tracker with Prejournal

[michielbdejong]

From https://github.com/federatedbookkeeping/timesheets/wiki/Follow-on-Project-Proposals-and-Milestone#strawman-simple-bug-tracker

[michielbdejong]

The monolith solution would be pretty similar to the generic MVC solution, running one Prejournal instance as a server with a long-lived database, and having 3 user accounts (one for each company). We would need to add a movement type 'task' for bugs probably, since so far movements can only be of type 'invoice', 'payment', or 'worked'. I guess 'worked' more or less relates to 'task' in the same way 'payment' relates to 'invoice'.

The comments can be statements.

We support a few different access control systems:

• admin party: everything is allowed; used mainly when running Prejournal as a script
• business logic: Turing-complete but hard-wired access control filters in each command
• component grants: components and statements from other users are hidden by default, but become visible when that user grants you access to either the "from" or the "to" component of that movement
• open mode: everything is visible and everybody can add new data, but you can only update data that you yourself added
• component claims: you need to explicitly claim a component before you can use it as the "from" component of a movement. This is what we use, in combination with open mode, on time.pondersource.com.

So I think my approach would be:

• choose 'business logic' mode
• company A would create the bug and as its creator be able to do everything it needs to
• create 6 component grants (A/B/C -> A/B/C), so that each company can see (but not edit) all the comments of each other company
• Companies B and C would be able to add&edit comments and see the bug status, but not to change the bug status or eit comments from others
• [missing Prejournal feature] Add a 'draft' flag that hides comments from others if set
• [missing Prejournal feature] Add a sort of grant that overrides the 'draft' flag if set
• [missing Prejournal feature] Add a sort of grant that allows B to also edit the bug status

[michielbdejong]

Maybe the list of possible grants is becoming a bit unwieldy this way. I don't know if there is a better solution, maybe refactoring the whole access control system. Food for thought! :)

[michielbdejong]

Going from a monolith solution to a 3-node federated network, the obvious way would be that instead of the (GUI) client sending its commands to 1 API, simply send it to all 3. Except when it's a draft comment and the current user is user A or user B, then you would only send it to node A and node B, not to node C. And the client doesn't know this, because that business logic only exists server-side.

So then maybe the (GUI) client sends the operation only to your own node and then your node checks which other nodes are allowed to see the item that was updated, and does filtered diff propagation that way.

[mcalligator]

Updating thread with new reference link replacing the one above following tidy-up of source Wiki page.

[mcalligator]

Generalising the problem in a 3-party system (whether a single instance of Prejournal or a federation of 3 Prejournal nodes, or different systems), there are 7 read access scenarios (given by s = n^2 - (n - 1) in general, where n is the number of parties or nodes):

1. Data private to A alone;
2. Data private to B alone;
3. Data private to C alone;
4. Data readable by only A and B;
5. Data readable by only A and C;
6. Data readable by only B and C; and
7. Data readable by A, B, and C.

For write (discounting immutable and write-only data), we have the following 16 scenarios (which effectively include the 7 above, and can be generalised as s = (n + 1)^2):

1. Data writeable by A, but read-only to B and C;
2. Data writeable by A, but read-only to B, and inaccessible to C;
3. Data writeable by A, but read-only to C, and inaccessible to B;
4. Data writeable by B, but read-only to A and C;
5. Data writeable by B, but read-only to A, and inaccessible to C;
6. Data writeable by B, but read-only to C, and inaccessible to A;
7. Data writeable by C, but read-only to A and B;
8. Data writeable by C, but read-only to B, and inaccessible to A;
9. Data writeable by C, but read-only to A, and inaccessible to B;
10. Data writeable by A and B, but read-only to C;
11. Data writeable by A and B, and inaccessible to C;
12. Data writeable by A and C, but read-only to B;
13. Data writeable by A and C, and inaccessible to B;
14. Data writeable by B and C, but read-only to A;
15. Data writeable by B and C, and inaccessible to A; and
16. Data writeable by A, B, and C.

This has been somewhat simplified by excluding the 3 scenarios where data are writeable by only one system and inaccessible to others.