FSM Design

[sumboid]

Description

FSM is linked to something, it could be object or space for now, maybe we can create FSM linked to app: for recruiting plugin we have specific FSM per vacancy since vacancies may have different flows, for tasks, at least how it is implemented now, we should have FSM per space.

Model

export interface FSM extends Emb {
  states: Ref<State>[]
  transitions: Map<Ref<State>, Ref<State>> // from -> to
  classes: Ref<Class<Doc>>[] // classes that can work as this FSM
}

export interface State extends Doc {
  name: string
  ...
}

export interface WithFSM extends Doc {
  fsm: FSM
}

// Until we are not sure about multiple FSM case 
// let's limit it by one
export interface WithState extends Doc {
  fsm: Ref<WithFSM>
  state: Ref<State>
}

Presenters

Just a multiple comments, within plugin there would be defined at least state presenter and fsm board presenter. Currently they are in different places. Also we need to make it possible to edit specific FSM and create it as object part if it makes sense.

Examples

Recruiting

WithFSM will be mixed in with Vacancy object, when we apply Candidate to specific Vacancy we need to mix in WithState like this:

{
  fsm: VACANCY_REF,
  state: APPLIED_STATE_REF
}

Tasks

The idea is the same, but WithFSM should be mixed in with Project space, task fsm would be space ref.

Shop

In shop case we have application-wide FSM, common for all orders.

Actions

Just to keep in mind that having FSM is not enough to build anything we want. :) There won't be full description, just an idea how it would work for FSM. I plan to open another issue related to that when it be done.

Let's define action as something that can be done within state and target object context: send message, create object like interview, add some info, or wait for some external event.

Updated model

It may look something like this:

export interface State extends Doc {
  label: string
  actions: FSMAction[]
}

export interface FSMAction extends Emb {
  action: Ref<Action>
  required: boolean
}

declare interface Action // external plugin declaration

Recruiting with actions

1. Applied
   Required action is attaching/filling actual resume/cv
2. HR interview
   Required action is interview. The action result would be recruiter feedback.
3. Test task
   Required action is to plan review: share source code, assign reviewers, wait for review and feedback. Probably additional action would be wait for candidate and result would be source code, additionally we can split it to awaiting test task and test task review
4. Technical interview
   Required action is interview. The action result would be interviewers feedback.
5. Offer
   Required action is to discuss with candidate and get feedback (can be simplified to fill feedback, optional action would be generate and send offer via email/messenger)
6. Contract signing
   Required action is just approve that contract is signed
7. Rejected

Transitions here are 1 -> 2 -> 3 -> 4 -> 5 -> 6, and we can go to 7 from any state.