type.copy_into_input: An Input type copies every field of another type with include, so a request could set any of them

An Input type copies every field of another type with include, so a request could set any of them.

Area 2, Values and types; not declinable; the next step is usually the human's.

Why Jadpo refuses it

An Input is what arrives from outside, such as a request body. include: [Todo] would accept every field Todo has, and every field added to Todo later, so a caller could set a field nobody chose to let them set. This is the mass-assignment bug.

Jadpo won't pick the fields for you. Which fields a request may set decides what callers can change in your data.

What it looks like

main.jadpo:

example

type CreateTodo = Input {    include: [Todo]}

jadpo checkcheck failed: 1 error, 2 files

error CreateTodo is an Input and can't use include

--> main.jadpo:2:5

  |2 |     include: [Todo]  |     ^^^^^^^ copies every field

reason: include would also accept every field added to the source type later, so a request could set fields nobody chose to expose.
next: Name the fields this input accepts with pick: [...] (human)
rule: type.copy_into_input
help: https://jadpo.dev/docs/errors/type.copy_into_input

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides which of Todo's fields a request may set.

How to fix it

If a request should set some of Todo's fields, name them with pick:

example

    pick: [Todo.title]

CreateTodo now accepts only title, with Todo.title's rules. A field added to Todo later isn't accepted until you add it here. Generated fields such as id can never appear in an Input.

Why Jadpo refuses it

What it looks like

How to fix it

Related