069 client note: Flow PT REST finding

Q Can a Note be made client-facing over REST?

Endpoint GET /schema/Note/fields ; POST /entity/notes ; PUT /entity/notes/<id> ; POST /entity/notes/_search

Docs claim Silent. The REST reference lists client_note as a checkbox and says nothing about who may write it. The web application ties the "Client Note" toggle to it.

Actual

GET /schema/Note/fields
  client_note:  data_type 'checkbox', editable False, mandatory False, default None
  sg_note_type: data_type 'list',     editable True,  mandatory False, default None
                valid_values ['Internal', 'Client']

POST /entity/notes {"project": {...}, "subject": "...", "client_note": true}
  as the script  -> 400 code 104 "API create() Client Notes can not be created through the API"
  as the person  -> 400, the same
POST ... "client_note": false
  as the script  -> 201, the echo omits the key, a re-read returns False
  as the person  -> 201, the same

PUT /entity/notes/<id> {"client_note": true}   (and false; as the script and as the person)
  -> 400 code 103 "API update() Note.client_note is editable on create only."

POST /entity/notes {..., "sg_note_type": "Internal"} -> 201, re-read 'Internal', client_note False
POST /entity/notes {..., "sg_note_type": "Client"}   -> 201, re-read 'Client',   client_note False
POST /entity/notes {..., "sg_note_type": "zzznope"}  -> 400 code 104 "Invalid field value, update
   failed [5 - Update failed for [Note.sg_note_type]: 'zzznope' is not a valid list value.
   Valid list values: 'Internal', 'Client'.]"
PUT /entity/notes/<id> {"sg_note_type": "Internal"}  -> 200

POST /entity/notes/_search, scoped to the sandbox project of 330 Notes
  client_note is true      -> 200, 0        sg_note_type is 'Client'    -> 200, 108
  client_note is false     -> 200, 330      sg_note_type is null        -> 200, 41

Teaches

Two refusals, one field. The create path answers Client Notes can not be created through the API, and the update path answers Note.client_note is editable on create only. Read together they close every route: the only call allowed to set the flag refuses true, and false is what an omitted key already stores. The schema's editable: false is right here, unlike created_at (probe 070). sudo_as_login changes nothing; the refusal is on the API, not on the identity.

sg_note_type is what a REST caller can write. Both fields are stock (visible.editable false, probe 056). sg_note_type is an ordinary list: a value outside valid_values is 400 with the vocabulary in the error, a PUT is 200, and is filters count it. On the probed site the vocabulary is Internal and Client; read it from the schema, never assume it. Setting it to Client leaves client_note false, so a client written this way is invisible to a filter on client_note.

Filter both when listing client-facing Notes. A Note the web application flagged and a Note the API typed are two disjoint sets: client_note is true finds the first, sg_note_type is "Client" the second. On the probed sandbox, 0 and 108 rows.

Python equivalent

# probe 069: the one client-facing marker the API accepts
sg.create("Note", {"project": {"type": "Project", "id": pid}, "subject": "...",
                   "sg_note_type": "Client"})
# sg.create(..., {"client_note": True}) -> Fault: Client Notes can not be created through the API