Но даже у них, что бы подключить API для вывода денег нужно юр.лицо. А вывод средств, это часть минимального функционала.
В биллинге вывод средств осуществляется по заявке пользователя вручную. Никаких АПИ там не используется. А перевести с Юмани на любой другой кошелек или через СБП на счет многих банков можно в ручном режиме.
Билинг купить не возможно! R2 на связь не выходит.
А давно отправляли деньги?
Биллинг, как ни крути,это некая финансовая ответственность перед пользователями. И «сбои» в компоненте могут привести не только к репутационным, но и финансовым потерям. Поэтому знать, кто будет автором данной разработки очень важно до начала голосования и самой разработки. Я хоть и проголосовал за вариант «Бесплатно» 😄, но от некоторых местных разработчиков я бы и за бесплатно не хотел бы использовать биллинг на «своих» проектах.
Чтобы не было инакомыслия и ухода темы в пустоту, речь идет конкретно о биллинге, а не про другие разработки от тех же разработчиков.
Как вариант «за дорого», можно использовать это поле. В нем пользователи сами смогут забивать нужный год, если его нет в списке.
тему создал пользователь, не разработчик компонентов… Вы же начали обсуждать как разработчики...
Что поделать, группа у нас такая, так и думаем )). Lora, написал, причину по которой он не сделал аналог биллинга, мы ему предложили варианты, как это можно обойти. Теперь видимоон занят, сидит строчит код нового биллинга )).
Проблема с интеграцией платёжных систем. Если раньше можно было легко получить ключ и протестить код, то сейчас с этим не так просто. Имхо.
Вообще, проблем никаких нет. Просто почти все платежные системы работают с юр. лицами и только им предлагают тестовые ключи и доступ к API и чаще всего только после заключения договора. Но есть Юмани для физ. лиц. Вы можете легко написать компонент с одной системой оплаты, а когда появится реальный покупатель, который предложит подключить другую систему оплаты, то вы сможете добавить ее к вашему компоненту и протестировать используя тестовые ключи предоставленные заказчиком. Так что Lora, ждем от вас новый аналог биллинга ))).
А урл какого вида должен быть в 'save_action' => ''? Имеется ввиду имя таблицы? И что указать в 'renderer' => '', ?
Таблица указывается в экшене github.com/instantsoft/icms2/blob/master/system/controllers/admin/actions/controllers.php#L13
Приведите ваш экшен к виду как по ссылке, то достаточно будет указать 'editable' => []
Эти строки github.com/instantsoft/icms2/blob/master/system/controllers/photos/actions/view.php#L255-L256 у вас как выглядят?
А в нотисах «on line 255» остались такими же как на скрине или цифры поменялись после настройки компонентов?
В настройках поля в «Тип поля» уберите «Номер телефона» или сделайте его другим строковым полем. Поле «Список телефонов и мессенджеров» не заточено на подстановку номера телефона в другие поля. И в целом номер телефона лучше содержать отдельным полем в маркетплэйсе для пользователей, а не в обшей куче с месендажерами и другими телефонами.
Ребята, есть ли какие то мысли о том, что я мог натворить?
По нотисам с картинками надо пересохранить настройки пресетов в компоненте «Загрузка изображений».
Donto, смотрите в консоли браузера ошибки яваскриптов.
Насколько я знаю, чтобы авторизация не слетала при переходе с одного домена на другой, файлы этих сайтов должны лежать на одном сервере. Если вы создадите одну базу данных и прицепите все остальные домены к ней вы получите один и тот же сайт на разных доменах. Как псы к этому отнесутся никто вам не скажет. Плюс поддержка всех доменов в одинаковом сосотоянии при изменении или обновлении движка на «главном» из них привлечет дополнительные проблемы. Если и это вас не остановит, то используя витрину товаров, вы не сможете организовать мультишоп или маркетплейс для нескольких продавцов, как ни старайтесь. Не заточен он под многопользовательский режим, ни сам магазин, ни платежные системы в нем.