Коли структура дрянь — руками пиши какие ресурсы выводить.

Просто &parents=`-2`

не получается, структура такая, нужно вывести вложенного родителя и потомков с id 7

РОДИТЕЛЬ НЕ НУЖЕН — 2
— ребенок не нужен
— ребенок не нужен
— РОДИТЕЛЬ НУЖЕН — 7
— ребенок нужен
— ребенок нужен

Когда ты указываешь

&resources=`7`
&parents=`7`

В запросе будет что-то типа «parent IN (7) AND id IN (7)». Соответственно если тебе нужно вывести 7 ресурс и его потомков указывай в parents родителя ресурса 7, а в resources тех соседей ресурса 7, которых не нужно выводить со знаком минус.

это понятно, а как вывести потомков тоже?

Если указывается &resources=`7` то выведется в любом случае только ресурс с id 7

Так не сработает, так выведет только ресурс с id 7, а мне нужны еще и его потомки.

parents — это родитель, у ресурса 7 родитель не может быть 7. Уберите &parents=`7` и все заработает

Не знаю почему у вас работает. Я отрыл в документации (и даже по той ссылке что вы дали на mdn это тоже написано), что включение mode no-cors позволяет использовать только простые запросы.
Кстати до сегоднешнего дня не знал, что запросы делятся на простые и сложные. Но как оказалось, если запрос содержит content-type — aplication/json он уже считается сложным.

Простой запрос – это запрос, удовлетворяющий следующим условиям:

Простой метод: GET, POST или HEAD
Простые заголовки – разрешены только:
Accept,
Accept-Language,
Content-Language,
Content-Type со значением application/x-www-form-urlencoded, multipart/form-data или text/plain.

Любой другой запрос считается «непростым». Например, запрос с методом PUT или с HTTP-заголовком API-Key не соответствует условиям.

If mimeType’s essence is not «application/x-www-form-urlencoded», «multipart/form-data», or «text/plain», then return false.

Поэтому насколько я понял, fetch принудительно меняет заголовок на text, если я указал mode no-cors.
Хотя у вас работает.
Я тоже грешил на сервер, потому что это мной построенные на docker целый кластер из контейнеров, с двойным проксирование запросов и напартачить там можно было во многих местах. Но запросы с postamn, curl — проходили правильно, с корректным content-type.
Пришлось более глубоко вникнуть в работу cors. Убрал из fetch no-cors и реализовал у себя в приложении обработку предзапроса по методу options. Полнейшее для меня открытие, но оказалось что как только мы хотим сделать «сложный» запрос на «не свой домен», перед основным запросом браузер отсылает предварительный запрос на тот же url но только методом options и просит разрешения на основной запрос.
Как только я организовал у себя обработку этих предзапросов и возврат корректных (по документации заголовков), у меня все заработало.

Прекрасно, что удалось открыть что то новое для себя и спасибо за подсказки.

Возможно у тебя какой-то прикол в настройках сервера.

// index.js

const btn = document.querySelector('#send')

btn.addEventListener('click', async () => {
  const user = {
    phone: '+0000000000',
    password: '76c4a096d14',
  }

  const response = await fetch('/test.php', {
    method: 'POST',
    mode: 'no-cors',
    headers: {
      'Content-Type': 'application/json;charset=utf-8',
    },
    body: JSON.stringify(user),
  })

  const result = await response.json()
  console.log(result)
})

// test.php

<?php

echo json_encode([
  'CONTENT_TYPE' => $_SERVER['CONTENT_TYPE'],
  'Content-Type' => getallheaders()['Content-Type']
]);

// Ответ сервера

{"CONTENT_TYPE":"application/json","Content-Type":"application/json"}

Тык

Можешь вообще эту оцию не использовать, она, по-моему, бесполезная. CORS запрос сделать не поможет, а для чего ещё её можно использовать непонятно.

я понял, это наверное изза

mode: 'no-cors',

А ну может. Не помню уже, редко пользуюсь этим полем.
Да вообще мысль хорошая. Нам не помешал бы конструктор полей по которым нужно искать.

Не, Пользователь это из раздела Пользователи, по нему ищет поиск стандартно. А нужно искать по полю reciever, это с вкладки Адрес в заказе, поле Получатель.

Дык есть же поле Заказчик. Это и есть receiver

Чет сомневаюсь, что без правок возможно, по крайней мере на чистом miniShop2.
Еще минус правок в том, что после обновления затрутся изменения.
Как вариант, можно, наверное, свой js подрубить в панель заказа и через него запускать php-код и возвращать нужное, НО это чисто теоретический вариант, не подскажу конкретнее…

Если делаю этот же запрос, но через postman, выбрав body->row-json
то запрос на сервер приходит с корретным Content-Type.

Так же проверил, что fetch автодектит тип данных и если совсем удалить заголовок и передать в запросе FormData, то он подставит заголовок корректный.
И я даже согласен с тем, что json по своей сути это текст, а значит можно сказать что fetch передал по умолчанию заголовок Content-Type:text/html, но почему он игнорирует заданный в парметрах заголовок, пока для меня загадка.

Спасибо, а без правок исходников такое возможно вообще?

Здравствуйте!
Вот тут добавить github.com/modx-pro/miniShop2/blob/7f4ce610245860e06d89ec3d3abf72fd06a0fde1/core/components/minishop2/processors/mgr/orders/getlist.class.php#L52 свое поле можно.