Dolg

Мне тоже так показалось. Но никакие настройки в cPanel не менялись. И похоже, что cPanel просто отказывается создать аккаунт с несуществующим тарифом VH-2. Ведь в cPanel создан только служебный тариф-шаблон reseller_custom, а при создании аккаунта через wwwact в URL-е передается название тарифа (package-а) который на самом деле не создан. Этот механизм мне не совсем понятен (видимо параметры аккаунта еще передаются и в POST-запросе?) но раньше это работало.

Новая проблема. Панель, при попытке автоматической или ручной смены тарифного плана получает ответ cPanel "Sorry you may not create any more accounts with the package VH-2." где VH-2 это название тарифа. Эта проблема присутствует в последней доступной версии от 07.09.2009 При этом, вроде бы, аккаунты создаются нормально. А смена тарифа - вот такое сообщение в ответ. в самой панели создан аккаунт reseller_custom , как рекомендовано в readme.doc.

Очередное пожелание. Думаю, во избежание вот таких ситуаций: http://forum.hostobzor.ru/index.php?showto...13439&st=30 уместно сделать запрет на редактирование идентификационных данных пользователя самим пользователем. Т.е. хотелось бы видеть глобальную настройку - "запретить возможность повторного редактирования личных данных пользователем", а то может это не всем нужно хостерам. В таком случае изменение личных данных будет производиться вручную админом, по запросу и с процедурой проверки новых данных. Личными данными называю: ФИО и данные паспорта/организации.

Беда со спомом на очень многих хостинг-площадках. Ведь клиенты не готовы платить за тарифы, которые стоят на 30% дороже из-за используемой на сервере платной системы анти-спама? Как вариант, можно пользоваться Google mail, который предоставляет возможность хостить на их серверах Ваши ящики, с Вашим же собственным доменом. О том, что Ваши ящики находятся на гугле можно узнать лишь по заголовкам письма. Собственно сабж: http://www.google.com/apps/intl/ru/group/index.html

http://iana.org/domains/root/db/ Смотрите тут для любой интересующей зоны.

admin, я говорю о том случае, когда мне приносят тупо 1000 рублей и говорят "Андрей, это за хостинг, закинь ага?" или тоже самое кидают деньги на WM и стучат в аську "Я там 20WMZ сбросил, это за аккаунт ID-такой-то". Какой порядок действий для учета таких платежей?

Надо не поиск по панели делать, а реструктуризацию интерфейсов. Я может щас скажу обидно для кого то, но bPanel это нафаршированный функциями скрипт, но он не имеет достойной оболочки. С клиентской стороны еще не так плохо дела обстоят. А вот в админке черт ногу сломит. Тут как по срезу дерева - можно предположить, какие функции были года 2-3 назад, и какие "наросли" поверх старых. Прошу принять мою критику адекватно. Но нужен редизайн интерфейса (хотябы админки), и соответствующие логике изменения в работе функций. PS Надеюсь меня не забанят Но концепция bPanel немного уже не соответствует требованиям. Работа с клиентскими аккаунтами должна быть организованна более "плоско", должно быть четкое понятие лицевого счета, и уникальности аккаунта. Чтобы не было всяких статусов типа "HOSTING, DOMAIN-REG". Аккаунт должен быть един, и иметь просто набор инструментов/возможностей, которыми клиент может воспользовать а может и нет. Есть согласные со мной? PPS Лежит вот у меня тут ТЗ на разработку биллинга... интересно кому-нибудь?

Вот такой вопрос давно меня мучает. Многие клиенты мне платят наличными или другой не автоматической оплатой. Как правильно учитывать эти деньги в биллинге? Я вручную добавляю платеж в "Поступления (Платежи)", затем вручную, добавляю деньги в счет оплаты хостинга через кнопку "Информация" (над полями "Изменение даты:"). Это не совсем удобно. Может я не правильно делаю? Как нужно делать, чтобы при добавлении платежа в "Поступления (Платежи)" дни хостинга автоматом добавлялись? Или может сделали бы галочку рядом с этой кнопкой "Информация", которая позволяла бы так же автоматически добавить платеж в "Поступления". Конечно, иногда не нужно добавлять, если это, скажем компенсация какая-то. Поэтому хотелось бы галочку. Рассчет добавляемых дней, кстати в открывающемся окне тоже не совсем красиво. Лучше бы количество дней сразу показывалось, пересчитываясь из введнного значения с пом. JavaScript.

Никак нет. Не могу утверждать, но помоему до обновления 08-08-09 (само обновление скрипта я произвел вчера, 10 августа) этого поля вообще не было. Не помню, потому что у меня всего одна такая Персональная услуга, создал ее - и забыл, не беспокоила. А сегодня вот такая ерунда. Клиента завалило спамом. Он мне пишет, мол продолжают сыпаться письма - на самом деле сыпались остатки, не могут же все 13000 писем в один момент быть доставлены. более 13 000 писем было отправленно кроном за время жизни скрипта - 60 сек. Неплохой результат, как вам такой бенчмарк? Я в попыхах лезу в админку (хотя понятно, что уже поздно метаться), смотрю что да как. И вижу вот это поле "Дата последнего выставленного счета:" со значениями "01 01 1999 - 00:00:00". Т.е. эти значения были установленны после обновления скрипта. Сразу и понял, что это и есть причина отправки уведомления, а такое их количество - видимо бесконечный цикл в PHP-коде. Поменял дату на бОльшую, чем "Дата начала выставления счета:". Надеюсь при очередном запуске крона глюк не повторится. Тем не менее, у кого-то этих Персональных услуг, на момент обновления скрипта, могло быть и 10 и 20... Исправьте.

Маленькое предложение: может сделать меню в админке чтобы открывалось по клику (а подпункты уже как есть по OnMouseOver-у) ? Как все нормальные меню. А то при перебежках между вкладками браузера, мышка постоянно проскакивает над меню, и оно туда-сюда мельтешит: следовательно обостряет нервозность, увеличивает утомляемость админа.

Клиентов засыпало самом от Автомата выставления счетов Глюк начался после обновления до bPanel от 08-08-2009. Буквально за одно утро одному клиенту было отправлено более 13000 писем-напоминаний. Скриншот прилагаю. Остановить появление новый инвойсов удалось только проверив настройки самой Персональной услуги. Вероятно, дело было в том, что дата последнего выставленного счета была "01 01 1999 - 00:00:00", и ведь логично - счет еще ни разу не выставлялся, персональная услуга была добавлена недавно и оплачена на 6 месяцев вперед. Я не помню в прошлой версии такого поля как "Дата последнего выставленного счета", вероятно оно было добавлено в последнем обновлении, и в поле устанавливалась дата по умолчанию. Непонятно только почему сразу 13000 напоминаний было выслано - это явно бесконечный цикл где то в скриптах. Логично было бы, если бы письмо высылалось каждый день. Слава Богу что у меня только одна такая Персональная услуга фигурирут, иначе бы за спам расстреляли, вместе с Вами. Считаю этот баг критическим, и требующим срочной заплатки.

Ребят, а планируется ли какое-то улучшение формы заказа выделенного сервера? Хотелось бы конструктор, можно в несколько шагов. Просто чтобы не забивать таблицу тарифов кучей вариаций одного и того же сервера, но в тоже время чтобы велся какой-то учет по каждой индивидуальной конфигурации. Я предлогаю вынести все что касается выделенных серверов в 4 отдельные таблицы БД: запчасти, группы запчастей, готовые конфиги (которые собраны из запчастей), и заказанные клиентами конфигурации. В 1ю (запчасти) закидываются все возможные железки для апгрейда сервера. Просто все возможные модели CPU, HDD, и т.д. ID, GID (ID группы), NAME, COST (ежемесячная оплата), SETUP (разовая оплата). Во 2ю (группы запчастей) делаются записи, группирующие зап части. ID, NAME (публичное название группы: HDD основной, HDD дополнительный, CPU... будет показываться в конструкторе у клиента), SNAME (Service Name - сервисное имя, которое будет показываться в админке, может быть "HDD SATA основные для серверов в США"). Деление на группы так же позволит различать HDD для серверов в России и для серверов в США, например. В 3ю (готовые предложения) добавляются базовые конфигурации-шаблоны, при их создании группы выбираются галочками, а для каждой группы еще и выбирается элемент по умолчанию (элементы сортируются по ежемесячной цене). Структура: ID, NAME (название конфига т.е. тарифа т.е. шаблона), COST (цена без учета всего навесного железа. Грубо говоря стоимость корпуса+мат. платы+блока питания), SETUP, GIDS. В GIDS (Group IDs) информация пишется наподобии такого: 2-5;3-1;8-6, где первое число это ID группы, а 2е число это ID элемента по умолчанию. 4я таблица аналогична 3й. В 3ю таблицу добавляется конфигурация каждого арендуемого сервера. ID, UID (ID клиента), TID (Template ID, ID шаблона), TNAME (сюда сохраняется название шаблона, на основе которого собран сервер), COST (сюда сохраняется уже просуммированная ежемесячная стоимость, и именно она обсчитывается биллингом, а SETUP смысла нет хранить - счет за установку выставляется только однажды), GIDS (как в 3й таблице, IDгруппы-IDвыбраннойЖелезки;IDгруппы-IDвыбраннойЖелезки...), CACHE (КЭШ - кэш конфигурации, сюда записывается в удобо-читаемой форме вся конфигурация сервера. Этот текст отправляется на мыло, а так же может быть просмотрен юзером в своей панели). Хранить название шаблона, просуммированную цену и текстовый кэш конфигурации нужно еще и для того, чтобы после установки сервера можно было удалить из базы некоторые железки. Например поставил 2 года назад Вася какой-нибудь Celeron, а щас уже и не продают такие. Сервер у Васи еще 2 года может стоять, но зачем ради него одного в базе будут старые Celeron-ы и шаблоны на их основе. А вот если Вася захочет апгрейдиться, то попадая в конструктор видит все, что доступно на данный момент для его шаблона (если шаблон с таким ID еще есть в 3й таблице). А если же уже и шаблона такого нет, то Вася отсал от жизни, и пора заказывать новый сервер. Будущий клиент видит на сайте небольшой список основных конфигураций. При переходе к заказу первым делом клиент попадает в конструктор конфигурации, где может изменить ее с помощью компонентов доступных именно для этой конфигурации. Вот как-то так. Конечно дело еще немного соложняется всякими проверками в коде и защитами от дурака, но помоему оно того стоит. На мой взгляд такой конструктор позволяет представлять информацию о выделенных серверах более структурированно и удобно для клиента (ну это еще ладно), и очень удобно для администратора. PS Надеюсь я правильную тему выбрал.