Add decisions (and consultations) into the ODP schema

[apricot13]

Starting the discussion for adding decisions into the ODP schema.

From the perspective of the DPR we're using only a handful of fields. There has already been a proposal about the data structure here so some of the fields we're using from BOPs will likely match up nicely.

Questions to discuss Tuesday 19 November 2024

• Should decision data be separate to consultations or combined with?
• What structure should the above fields have
• What other data should be included in the schema

DPR data

This is the data we're currently using in displaying decisions, it currently comes from BOPs.

application: {
  status:
    | "pending"
    | "not_started"
    | "invalidated"
    | "assessment_in_progress"
    | "in_assessment"
    | "awaiting_determination"
    | "in_committee"
    | "to_be_reviewed"
    | "determined"
    | "returned"
    | "withdrawn"
    | "closed";

  receivedAt: string;
  publishedAt?: string | null;
  determinedAt?: string | null;
  decision?: string | null;
  validAt: string | null;

  consultation: {
    endDate: string | null;
    publishedComments: DprComment[] | null;
    consulteeComments: DprComment[] | null;
  };
};

Other links & References

• beginnings of a proposal for the structure of the planning decision data
• Planning applications & decisions

[apricot13]

In our recent discussions we discussed grouping data by decision and consultation for the basic structure:

interface PlanningApplication {
  application: {
    decision: {
      receivedAt: string;
      publishedAt?: string | null;
      determinedAt?: string | null;
      decision?: string | null;
      validAt: string | null;
    }
    consultation: {
      endDate: string | null;
      comments: {
        enabled: boolean;
        published: DprComment[] | null;
        consultee: DprComment[] | null;
      }
    };
  };
}

After thinking it over a bit more last week, we realised that with the appeals process - and to make the API easy to use, even for people who aren’t familiar with planning processes - it might make more sense to go with a timeline approach. This is especially helpful for stages that can happen more than once - or potentially more than once in the future.

Here is an updated proposal:

interface PlanningApplication {
  application: {
    timeline: {
      type:
        | "recieved"
        | "published"
        | "determined"
        | "valid"
        | "decision"
        | "consultation";
      date: string;
      ref: string;
    }[];

    decisions: {
      ref: string;
    }[];

    consultations: {
      ref: string;
      startdate: string;
      endDate: string;
      comments: {
        enabled: boolean;
        published: DprComment[] | null;
        consultee: DprComment[] | null;
      };
    }[];

    appeals: {
      ref: string;
    }[];
  };
}

A timeline structure would make things more flexible and easier to understand. It still keeps the datasets separate for compatibility with MHCLG and organises everything in a way that works well for stages that repeat, like (potentially) consultations and appeals, and it’s simpler for developers who don’t know all the details of the planning process!

[apricot13]

Adding to this that I have now created a branch with a proposal for published Application schema which includes a lot of this work.

https://github.com/theopensystemslab/digital-planning-data-schemas/blob/hn/published-application-schema/types/schemas/publishedApplication/index.ts

[apricot13]

I have now created a PR for this #306