Добрый день!
Ну тогда некорректно поставлена задача:
Нужен только разработчик функционала, дизайн и верстка уже есть.
Если нужно будет, что-то, разработать уникальное, обращайтесь.
А на эту задачу, наверняка кто-то найдётся, благодаря нашим комментариям, и приступит к настройкам.
А это наследие от клиента, который заказывал этот компонент а потом переключил меня на другое.
Я ещё много вырезал, там и контроль остатков был, и оповещение менеджеру о статусе кол-ва «Ноль», и возможность разрешать подписку тем или иным (авторизован/не авторизован), и возможность выбора проверки адреса почты с подтверждением или через проверку записи DNS… (не помню, это я сам придумал или он заказывал, точно знаю — что ему нужен был реальный адрес почты — всё сразу пишется в рассылку (Sendex), любитель, умеренно, поспамить, просто))), ну и т.д.
Зачем обязательное имя и количество?
Имя нужно для обращения к человеку посредством обратной связи — это правильно, мне кажется.
Количество: оно не обязательно, можно вырезать из формы — будет один всегда. Замысел был такой: ведётся учёт всех ожидающих товар, с выводом в бекенд, где в первую очередь показываются самые востребованные — статистика, одним словом.
Если клиент введет, допустим 2, то если товар 1, то ему никогда не придет оповещение и даже этот 1 товар ему не продадите.
Так вот для этого и нужно кол-во предполагаемой покупки. Всё правильно, как мне кажется, — зашёл менеджер в таблицу ожидаемых товаров, накинул сверху n-ое кол-во и отдал в отдел поставок (ну или заказал/купил) — разослал уведомления потенциальным заказчикам.
Просто мы, наверное, разные вещи подразумеваем, — ведь товар может быть не только розничный, но и оптовый.
Да даже если и розничный, в штуках, ведь, не всё меряется, допустим в строительстве…
Так и каким в итоге способом происходит оповещение?
Пока ни каким, поэтому и alpha-тестирование.
У меня есть мысли по поводу оповещения, как со стороны заказчика, так и от себя.
Хотелось бы услышать разработчиков, работающих со своими клиентами — их мысли, чтобы этот компонент был максимально универсален.
Да и потом addData не привязан к miniShop2, он работает с любыми ресурсами.
Ну тогда некорректно поставлена задача:
Если нужно будет, что-то, разработать уникальное, обращайтесь.
А на эту задачу, наверняка кто-то найдётся, благодаря нашим комментариям, и приступит к настройкам.
1. mSearch2
2. Импорт/Экспорт
3. Для ЯндексМаркета есть это msYmarket, для гугла можно настроить здесь
4. Если имеется ввиду sitemap, то в pdoTools есть сниппет pdoSitemap
5. miniShop2 это умеет делать.
6. Tickets
7. HybridAuth
8. easyComm — рейтинг, комментирование. Сравнение товаров Comparison
Не понимаю, что тут нужно ещё разработать?
А много вообще записей в БД?
Нужно детально всё обсудить.
Контакты в профиле.
Пришлите ТЗ на marat@marabar.ru
Рад, что всё получилось!
По остальным вопросам ответил выше, спасибо за вопросы!
Я ещё много вырезал, там и контроль остатков был, и оповещение менеджеру о статусе кол-ва «Ноль», и возможность разрешать подписку тем или иным (авторизован/не авторизован), и возможность выбора проверки адреса почты с подтверждением или через проверку записи DNS… (не помню, это я сам придумал или он заказывал, точно знаю — что ему нужен был реальный адрес почты — всё сразу пишется в рассылку (Sendex), любитель, умеренно, поспамить, просто))), ну и т.д.
Имя нужно для обращения к человеку посредством обратной связи — это правильно, мне кажется.
Количество: оно не обязательно, можно вырезать из формы — будет один всегда. Замысел был такой: ведётся учёт всех ожидающих товар, с выводом в бекенд, где в первую очередь показываются самые востребованные — статистика, одним словом.
Так вот для этого и нужно кол-во предполагаемой покупки. Всё правильно, как мне кажется, — зашёл менеджер в таблицу ожидаемых товаров, накинул сверху n-ое кол-во и отдал в отдел поставок (ну или заказал/купил) — разослал уведомления потенциальным заказчикам.
Просто мы, наверное, разные вещи подразумеваем, — ведь товар может быть не только розничный, но и оптовый.
Да даже если и розничный, в штуках, ведь, не всё меряется, допустим в строительстве…
Пока ни каким, поэтому и alpha-тестирование.
У меня есть мысли по поводу оповещения, как со стороны заказчика, так и от себя.
Хотелось бы услышать разработчиков, работающих со своими клиентами — их мысли, чтобы этот компонент был максимально универсален.
Должен сработать.