Пару дней мониторю эту тему! Вродь как все просто! На событии OnPageNotFound ловим урлы типа /api/v1/* подключаем класс компонента! Для реализации класса можно условиться, что вместо * идут основные параметры запроса разделенные слешами:
1) Тип ресурса
2) Метод
3) Критерий
Таким образом мы получим запросы типа:

/api/v1/resources/getlist/ = /api/v1/resources/ - получаем список сущностей - массив объектов
/api/resources/get/{$id}/ - получаем сущность - объект

Конечно же сервер должен вернуть нам JSON.
Ну а понимание того, что мы хотим сделать с ресурсом, нам даст метод запроса (GET, POST, UPDATE ...).
Сам класс компонента должен проверить права (тут есть вопросы!), корректно определить пожелания пользователя из запроса, произвести валидацию данных, дернуть соответствующий процессор и вернуть ответ!
Если админка только для разработчика, то для обращения по апи пользователь должен быть авторизован в текущем контексте и иметь соответствующие права.
Вродь как этого достаточно для старта, или я опять не вижу кучу подводных камней?

Добрый день!

Подскажите есть у меня дополнение для работы с данными. Там нужно создать таблицу, файлы залить может еще что-то.
Можно ли с помощью данного дополнения собрать свое, не имя навыков программирования?
На видео что-то уж ни чего не понятно что для чего делается…

Можно ли к примеру в несколько кликов сделать свое дополнение?

Спасибо.

Скорее, Розница. Но тут я мало помогу, я не спец по 1С.
1 вариант. Оставить в настройках mSync создавать tv-поля, сделать выгрузку и смотреть, какое поле отгрузилось, потом его привязать.
2 вариант. Смотреть Блок <Ид> / СписокЗначенийCML, но не точно.

Так мы вроде эту парадигму и обсуждали (и тут).
А по API что скажешь?

Там можно навесить плагин на каждую строку парсинга, вот так можно будет. Из коробки работа с msop не предусмотрена.

Позвольте спросить, а чем вам не угодил подход, который начинал пропагандировать лет 7 назад @Fi1osof?
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.

MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.

Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.

Здравствуйте, подскажите такой вопрос допустим парсим товары с сайта поставщика возможно ли будет вставить остатки в поле от компонента msOptionsPrice2?

В целом задача стоит такая. По сути реализовываем техподдержку по определенным устройствам. Устройства загоняются в админку как тикеты. Пользователь ищет своё устройство, открывает его и пишет комментарий. Далее по логике письмо идет админу сайта что в тикете сделан оставлен каммент. И пользователю на почту отправляется такое же

Предыдущему комментатору в этой ветке?

написать реализацию на событие OnCommentSave (поиск юзера, подготовка массива письма, вызов $ticket->addQueue)

> Возможно, в твоем случае администратор — создатель ветки, куда пишется комментарий ($uid == $owner_uid)
Этот момент я поборол установкой значения Уровень уведомления администраторов = 2

А есть ли возможность чтоб в момент создания комментария к тикету такое же письмо отправлялось и автору последнего, пусть даже и не зарегестрированного?

Какие есть предложения по API? RestAPI, JSON-API или GraphQL?

> Но уведомления о новом комментарии админу сайта не приходит
Вот полный набор условий, при которых отправка администратору может не идти
github.com/bezumkin/Tickets/blob/master/core/components/tickets/model/tickets/tickets.class.php#L1144

Возможно, в твоем случае администратор — создатель ветки, куда пишется комментарий ($uid == $owner_uid)

> Опять же когда из под админа в панели отвечаю на комментарий, то оповещение на почту пользователю не приходит. Если из фронта отвечать, то всё идёт на почту

Это моя недоделка, предлагал временное решение с плагином вот здесь — modx.pro/help/18026
В коробку пока еще не добавил, руки всё не дойдут отрефакторить систему уведомлений

Спасибо за информацию.

У меня такая выгрузка, называть нужно именно Старая Розничная или иначе?
prntscr.com/ow6vvs

Пробовали добавить в Настройках, вкладка — Настройка источника свойств:
Источник — Старая розничная
Поле — msProducts
Цель — old_priсe?

решением оказалось следующее, нужно очистить таблицы modx_msync_products_temp и modx_msync_products
но если их очистить, сброситься еще и привязка на уже привязанные товары

Не совсем правильный подход. Открываете default.js, ищите вызовы jGrowl и заменяете их. Нотификаторов в инете достаточно много. Можете даже свой написать и подключить в js.

modx.pro/help/9482

В комментарии человек отписал там способ

При загрузке pagetitle — скрипт меняет uri страницы, исходя из этого имеем две проблемы:

1. например, у товаров одинаковый pagetitle и разные артикулы. тогда скрипт выдает: обновлено столько-то товаров, ошибка — 1 (но не говорит в чем ошибка, товар не обновлен).

2. меняет url ранее созданных страниц, после чего нужно:
менять в базе 1С ссылку на страницу товара
или
настраивать редирект со старого url на новый (лучше, чтобы это делалось автоматически)

в общем, штука хорошая, и сильно облегчила мне жизнь.

но пока что крайне не дружелюбна к пользователю.

пользователю нужно дать обратную связь:
1) обновлены такие то артикулы
2) ошибки в таких-то строчках (ячейках)

Судя по описанию, да, так и будет работать. Вопрос нужен ли физический чек, если по тому же 54ФЗ на почту клиенту придёт чек электронный, чего вполне достаточно:

«5.3. Пользователи при осуществлении расчетов в безналичном порядке, исключающих возможность непосредственного взаимодействия покупателя (клиента) с пользователем или уполномоченным им лицом и не подпадающих под действие положений пунктов 5 и 5.1 настоящей статьи, обязаны обеспечить передачу покупателю (клиенту) кассового чека (бланка строгой отчетности) одним из следующих способов:

1) в электронной форме на абонентский номер или адрес электронной почты, предоставленные покупателем (клиентом) пользователю, не позднее срока, указанного в пункте 5.4 настоящей статьи;

2) на бумажном носителе вместе с товаром в случае расчетов за товар без направления покупателю такого кассового чека (бланка строгой отчетности) в электронной форме;

3) на бумажном носителе при первом непосредственном взаимодействии клиента с пользователем или уполномоченным им лицом в случае расчетов за работы и услуги без направления клиенту такого кассового чека (бланка строгой отчетности) в электронной форме.»