- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
lonelywoolf, как я и писал можно это изменить сделать длину в 20 символов например.
И нужно понимать, что это НЕ уникальный идентификатор. В админ части это ID (increments), а на клиентской это два параметра, один из которых номер тикета.
это НЕ уникальный идентификатор.
WHMCS считает по-другому. Но да ладно. Так что будет, если два номера совпадут? Правильно, в поиске будут вылезать несколько тикетов. Да, можно и 20 символов сделать, но у нас сейчас - 7 (!). Тут как бы не биткойн, хотя и там совпадения известны в узких кругах (ошибки ГСЧ, знаете ли).
В админ части думаю да. Но разве проблема идентифицировать нужный?
Из опыта скажу, что во всех крупных компаниях номера задаются более сложными. По этому проблем нету.
разве проблема идентифицировать нужный?
Для компетентного товарища - не проблема. А так - человеческий фактор он такой. Уникальность номеров запросов для того и придумали. Легко же было этого избежать - никаких затрат даже умственных для этого не надо, при генерации номеров тикетов. Но вот почему-то выбран был не лучший вариант. Казалось бы, нахрена козе боян?
во всех крупных компаниях номера задаются более сложными
Не во всех, но такое да, распространено. А иногда прикручивают дату/время.
Не во всех
Ну это проблемы конкретной компании. Главное, что решение имеется.
---------- Добавлено 29.04.2020 в 11:44 ----------
lonelywoolf, но на самом то деле по теории вероятности возможность повторения 6-ти значного номера очень и очень низкая.
вам может и надо извратиться, я не видел среди ауешников толковых программистов (правда я и с первыми не общаюсь, но это просто причинно-следственная связь)
на этом можно прекратить вас слушать в принципе.
посмотрите на таблицы тикетов в бд whmcs. ID - Primary, Auto Increment
TID - тот самый случайный ID который а) задается по маске, б) виден клиенту и админам в) используется для получения тикета в клиентской части и в) не используется в админской
даже если TID тикетов внезапно повторятся, ничего страшнего не произойдет - уникальный ID никуда не делся. Да, у разных клиентов будут тикеты с одним номером, но на логике биллинга это не отражается. При достаточном уровне смекалки и прямых пальцев легко заменить штатный псевдо-рандом на кое-что более интересное. Сами догадайтесь, не всегда же волчьи паблики читать.
Если уж кому-то и интересна правда, то вот количество обработанных заявок - не учитывая, конечно, удаленных - коих много.
на этом можно прекратить вас слушать в принципе.
Документацию читали? Вижу, что нет. К чему такая настройка может привести - я в общем-то описал. Не смертельно, но делать так не надо.
я не видел среди ауешников толковых программистов
Гхм. Ну расскажите, что такое АУЕ. А то я чет в этих молодёжных веяниях не силён.
даже если TID тикетов внезапно повторятся, ничего страшнего не произойдет - уникальный ID никуда не делс
О. Начинаете понимать. Круто. Теперь ещё немного подумать и станет в обзем-то ясно, почему так делать не следует. Мелочь, но дьявол кроется в мелочах.. Вы же сейчас рассказываете о собственной компетенции.
не учитывая, конечно, удаленных - коих много.
А. Ну сказал ж, не храните. Да, с вероятностью я ошибся - 0,1%. Но если бы вы их ещё и не удаляли... :D.
читали, смотрим:
перевожу для бестолковых:
id - уникальный ID тикета
tid - уникальный ID тикета показываемый клиенту и используемый для его загрузки в клиентской части
единственное, что не стоит делать с tid - использовать только его для получения тикета клиента через api. Когда как сам whmcs в клиентской части использует комбинацию TID + C.
короче, не понимаю, волк, что ты пытаешься доказать.
Ну. tid - уникальный номер
Вы же говорите, что
даже если TID тикетов внезапно повторятся, ничего страшнего не произойдет
Произойдёт. Если вы не пользуетесь той логикой в биллинге, для которой это в общем неприятно - я за вас искренне рад. Но по мнению разработчиков номер должен быть уникальным, и они на это рассчитывают. К чему подобное может привести - можете догадаться самостоятельно.
То есть так сложно к номерам тикетов допилить дату/инкремент из двух-трёх символов было? И сейчас сложно. Дааа.
Произойдёт. Если вы не пользуетесь той логикой в биллинге, для которой это в общем неприятно - я за вас искренне рад.
Нам это не доставляет никакого дискомфорта. И я не понимаю, почему вас это так задело
---------- Добавлено 29.04.2020 в 13:01 ----------
Хотя, весь этот холивар из принципа "лишь бы домахаться" - то кому-то не нравится счетчик клиентов, кому-то - счетчик тикетов, кому-то - отзывы новорегов, а кому-то - наличие бесплатного тарифа с верификацей.
Я думаю, команде HostiMan очень льстит такое внимание со стороны серчан-экспертов :))
---------- Добавлено 29.04.2020 в 13:03 ----------
и опять же, никаких фактов - пустой трёп 🚬