ddouglascarr/rooset

A democratic structured decision system

Rooset

Rooset is a democratic structured decision system. Work in progress

Set Up

Requiremnts

• docker
• docker-compose

Initial setup of development environment

  $ docker-compose up -d

  $ docker-exec lfcore bash
  # bmake
  # cd /opt/rooset/etc
  # ./init-dev-db

  $ docker-compose exec lffrontend
  # cd /opt/rooset/lfframework
  # bmake

Re-running init-dev-db will drop all data and reset the database to the development scenario.

Using the development environment

The relevant part of the host filesystem is mounted on top of the containers, so you can edit the code on the host, and it will appear in the contianers.

Run the containers

  $ docker-compose up

Start the core services. These will run every 5 seconds.

  $ docker-compose exec lfcore bash
  # ./core-services

Start the frontend server. There is no autorestart. It is available on the host at `http://localhost:8081'.

  $ docker-compose exec lffrontend bash
  # ./frontend-server

Webpack dev server will start automatically

There are a number of test users set up. All their passwords are `login`.

Usernames:
  - admin
  - determined_poitras
  - tender_hugle
  - dreamy_almeida
  - thirsty_swirles
  - goofy_heisenberg
  - thirsty_babbage
  - sick_lamarr
  - admiring_sammet
  - compassionate_bose
  - fervent_wright
  - focused_bell
  - elated_meninsky
  - romantic_carson
  - admiring_bartik
  - evil_austin
  - mad_mcnulty
  - insane_poincare
  - jovial_blackwell
  - goofy_khorana
  - kickass_fermat
  - drunk_saha
  - angry_ritchie
  - desperate_easley

rooset's Issues

automate config and testing

• set up lerna for all the js packages
• single bash script to configure and build all modules
• single bash script to run all tests

rooset-event-listener

• Java application that performs persistent one-time listening to $all and to projections
• Will call process manager in rooset-domain-command-posix
• Will populate the Elasticsearch read models.

logout

Handle logout.

• Endpoint in http that invalidates the cookie
• Reducer in web which sets the SessiontState to { status: "LOGGED_OUT" }
• SESSION_END event exists already

SchedulerTools

Implementation: SchedulerToolsSosJobSchedulerImpl

Features:

• Schedule Command
  • Sends job request to Scheduler to execute a command at a later date.

REVOKE_MEMBER_PRIVILEGE

Remove a member privilege from a unit.

Session

• http /session endpoint which responds data about a logged in user. (and 401 if not logged in)
• Remove the LogInResponse reducer, and add Session{Req,Res,Err} actions and reducers.
• Add a SESSION_REQUEST at app startup.
• Add a SESSION_REQUEST after logging in.
• Logout{Req,Res,Err} actions and reducers
• update SessionComponent to read what's in session when status === LOGGED_IN.
  • display a little persona
  • have a dropdown menu with log out.

change declaration format

Currently, delaration properties are expressed as '$type'. This needs to be change to something like

id:
  type: uuid
  description: Issue Id
  nullable: true
  foo: bar

implement http command interface

• create rooset-http-api
• implement user authentication in http api
• add HttpCommandRequest generators to ratk
• add HttpCommandRequest and Command java generators to ratk
• remove MemberAggregate and all associated bits from command

Login entrypoint

POST /login

{ "username": "foo", "password": "bar" }

Implement the last 2 issue phase commands

• CompleteissueDiscussonPhaseCommand
• CompleteIssueVerificationPhaseCommand

Make areas aware of currently edited sections

As a member I can only start an initiative if the sections in the area document I am changing are not currently edited by an issue that has been admitted.

implementation

• docsvc takes a BaseDoc in all operations. It responds with ChangedSectionIDs []String.
• lffrontend saves the ChangedSectionIDs, and BaseDoc in drafts
• lffrontend checks that an initiative has not section conflicts before merging
• lffrontend as a new SECTION_CONFLICT state it can be in. On admitting a new intitiative, put all conflicting initiatives into that state.

Future work

• need to rebase all these docs when an initiative succeeds. (The BaseDoc of all open drafts will be stale. There shouldn't be any merge conflicts due to above rules, but need to create a new draft with the new base doc).
• notify users when an inititiatvie in admission phase in SECTION_CONFLICT state.
• users can convert a SECTION_CONFLICT initiative into a competing initiative of one the issue they are in conflict with.

ratk test declarations: reference and export preconditions

Turns out #5 was a terrible idea. Made everything a mess.

Better way is to allow refrencing of the 'given' parameter (precondition) of each scenario. Both within a test declaration file and from outside. (one test declaration can import a scenario from another). This will also allow referencing those scenarios in saga integration tests.

Todo:

• rebase #5
• allow "given" to be a string in one of these formats:
  • "#/new-unit-created" : for referencing the given of another scenario in this file
  • "UNIT_AGGREGATE_TESTS/new-unit-created" : for referencing the given of another scenario
• add "testType" prop to test file declaration
  • enum "COMMAND_INTEGRATION_TEST", "HTTP_REQUEST_INTEGRATION_TEST"
• have getTests take the testType enum and filter test declarations that way.
• Allow getTests to take an ALL enum to return all tests (for getting all preconditions).
• Have getTests inject the preconditions referenced above
• getTests should GLOB test-dir/**/*.yaml
• Test Decl schema should be as below (To allow for proper gherkin-style logs)
  • label, key should be optional for all (getTests should generate if missing)
  • the given key is used for looking up when importing scenario
  • Add preconditions prop to allow for declaring them at the top. Look there first and export them
    Example test decl:

---
label: Unit Aggregate Tests
testType: COMMAND_INTEGRATION_TEST

preconditions:
  -
    label: Member granted permission
    key: member-permission-granted
    precondition: [ ... ]

scenarios:
  -
    label: Unit creator can grant privileges
    given: 
      key: unit-created
      label: Unit has been created
      precondition: [ ... ]
    when:
      label: Grant Privilege Command
      action: { ... }
    then: 
      label: Privilege Granted
      outcome: { ... }

  - 
    scenario: Non-privileged member cannot grant privileges
      given: #/unit-created
      when:
        action: { ... }
      then: 
        outcome: { .. }

Remove Member management from command

Managine authentication and signup will be responsibity of the http / ethereum api

Impliment Concerns, membershipPolicies

• Add concernId to issue aggregate
• Add concerns, policies, privilegePolicies to unit aggregate
• Add concern to delegation matrix
• Add membershipRole handler to vote, delegation handlers

update java tests to use eventstore 4.0.0

EventStore 4.0.0 has an installer, so we should get away without all the dodgy path and shell business. Just run eventstored.

implement web client

• Create the project
• Get navigation, basic page orginisation, login, routing working
• Add New unit and view unit functionality
• Commit after that, and implement features in own issues

Set up anisble

Set up ansible things before I forget how to set it all up.

So far, in addition to compiling the project, it needs to set up:

• GetEventStore
• Postgres
• SosJobScheduler

events should not have requesterId property

• Should be memberId in most cases.
• authoriserId in others
• Need system for mapping in the CommandConstructor declaration
  • commandConstructorPropMap { requesterId: memberId }

Persist precondition events from command line

For manual testing, have a command line tool that gets a test precondition and persists all the events to GetEventStore.

  $ persist-precondition issue-lifecycle-command issues-created

Have eventstore port and server set by env (defaults to localhost:2113)

Sagas / ProcessManagers

Sagas listen for events and execute commands. (Opposite of aggregates)

They handle side-effects. e.g.:

• Scheduling: interface with scheduler
• Outside systems: github

ScmTools

Tools for source code management.

Implementations:

• ScmToolsGithubImpl
• ScmToolsGitlabImpl (Later)

Feature Requirements:

• Open New Branch: open a new branch from master
• Validate pull request: validate pull request against master (idempotent)
  • For user pull requests. Referred to by url.
  • Does the pull request cause conflicts.
  • Should be able to specify other branches too. (For assessing future possible conflicts)
  • Will need to be run every time master changes, and every time the user updates the branch.
• CommitContentToBranch:
  • For suggestions. Client sends full modified content of files.
  • Set the content of file(s) to a branch. Takes complete file content, not a patch
  • Uses a map of filenames to String content
• MergeIntoBranch
  • For merging master into branch. Done whenever master changes.
• Credential Storage
  • Probs dont want to store github keys in the event store, so will need to use postgres (or something) to do that.

ci

• get circle ci working

unit: urlParameterName

rooset.org/my-unit the "my-unit" is the urlParameterName. It should be added to the unit created command, event.

Also need an http query url for it (GET rooset.org/unit-parameter-names/foobar => { id: uuid }

Will need to check for uniqueness, but that's a different issue. (Needed for usernames, names, etc. Will need a uniqueness processManager, or some sort of process in the http-api)

fix domain-query tests

• Generation is failing.
• add them to run-all-tests

rooset-command should return aggregateId

Currently returns just eventId, should get the aggregate id too.

This should be included in CommandServiceResponse in http-api.

Both rooset-command and the CommandServiceResponse should look like this:

{
  eventId: uuid0,
  aggregateId: uuid1
}

prefix aggregate streams with aggregate-

In order to use the stream filter feature in GetEventStore, prefix all aggregate streams with "aggregate".

AFAIK this will need changes is all the integration test systems.

Implement query reducers

• experiment with projections
• Build tooling to upload all projections to GetEventStore
• Generate javascript tests. These can use GetEventStore if necessary (initially, really shouldn't but 🤷‍♀️ )
• Add to http api. Test there too using current test generators with an HTTP_RESPONSE outcome

add persistent session managment

Enable cookie sessions in http-api

ratk tests should handle multiple given, then properties

Currently, tests must be of this structure:

{
  ...
  given: Array<Event>
  when: Command
  then: Event
}

To allow:

• for tests to be used in different contexts (e.g. test both an http request and a command)
• for test to reuse the same given events but test different command->event situations

This should be an option

// Each when expects the then at the it's index
{
  ...
  given: Array<Event>
  when: Array<Command|HttpRequest>
  then: Array<Event> //  then.length == when.length is required
}

The getTests() function should throw if the arrays are not equal length.

To facilitate test generation, getTests() should take an argument testTypeEnum. This will filter based on the type of the given bit.
Emit 1 test for each when. getTests() transforms them into old format, and filters based on test type.
How does it detect what given is which sort ? (Maybe, it's a command by default, HTTP_REQUEST is singular, as would ETHEREUM_COMMAND_INVOCATION)