Vladimir812

Также просьба сделать так, чтобы платежи не удалялись вместе с услугой, если они оплачены, т.е. +

Тот же тариф, который нельзя продлить, а можно только сменить при сроке ноль и менее пишет очень странную фразу: На данный момент у Вас закончился оплаченный срок действия аккаунта! Воспользоваться функцией изменения тарифного плана станет возможно только после оплаты за продление. Так ведь продлить тоже нельзя)

Есть аккаунт с тарифом, который нельзя продлить, а можно только перейти на другой. Есть MainID, к которому прикреплен этот заказ. Если из него перейти и попробовать сменить тариф, то : Перед оплатой, над выбором способа оплаты написано "Notice: Undefined variable: selected_txt_to_view in /home/****/public_html/index.php on line 20966". Если нажать далее, то - Введены неверные данные... Если непосредственно из заказа попробовать перейти, то ошибок нет.

Опять QIWI - добавляются платежи с копейкой, а не 2 платежа, в итоге +, но аккаунт в биллинге не активируется и на главной не выделяется никак.

Если клиент выписывает несколько счетов QIWI на одну услугу, то после зачисления платеж +, но аккаунт не продлевается по сроку. На других способах не проверял.

По доп. услугам все также, для проверки - 45951 и 51039

Сделайте за 5$, чтобы опционально можно было бы запретить активацию без верификации. Нельзя в случае наличия незачисленных платежей сделать выбор - авто платеж или ручной ? Это будет более эффективно нежели сейчас. Лично я попав на эту стр. сразу захотел бы заполнять о ручном платеже, так как с автоплатежом в данном виде не все очевидно. По SMS как я понял если не заполнены ответ и нет верификации телефона. то будет как в Вашем посте на скрине? А если будет только верифицирован телефон или только ответ? Что сможет делать клиент и какие уведомления будут в биллинге?

По уведомлениям хотел добавить - в данном виде клиенты будут заполнять в большинстве случаев то, что ниже ИЛИ, а не выбирать авто платеж или ручной как я и предлагал. Думаю требует доработки. Нужно выпадающее меню - автоматически или ручной платеж и далее уже клиент заполняет. Туда же - при выборе изменение тарифа видны тарифы другой группы других серверов, а не только доступные данному заказу. По остальным вопросам также очень жду изменений.

Еще хотелось бы хотя бы на будущее слегка расширить функционал перевода средств аккаунта на карту оплаты. Клиенты, которые имеют много аккаунтов в системе (ввиду ее специфической реализации, когда приходится делать много заказов вместо одного аля магазин-корзина), хотели бы видеть внутреннее управление средствами. Лично я это вижу так - клиент получает возможность вывода на карту оплаты части средств (вроде как при возврате, но сумма менее остатка без удаления аккаунта). P.S. Юр. лицам категорически запретить.

У нас в договоре приложение 2 это совсем не то и суммы только в спецификации видны, у не активированного аккаунта спецификации нет или я Вас не понял. "Служебное -> акты и счет-фактуры -> введите название компании в поле "Компания"." - такого нет в служебном, только сверка взаиморасчетов и ежемесячные акты ,где надо вводить не имя организации, а номер заказа. Перенаправление к модулю актов. Поясните где точно искать Вашу табличку.

По уведомлениям на Главную - выбор автоматический платеж или ручной. Если автоматический, то давать выбор платежей не оплаченных и по ним давать уведомлять. Если платеж ручной, то все как и прежде. По SMS суть такова, у клиента должен быть заполнен и вопрос-ответ и верифицирован телефон, если нет ничего, то предлагать заполнять и то и то, более приоритетно мне кажется телефон (более безопасно). Если что-либо есть, то работать с биллингом клиент может, но должен быть уведомлен, что по безопасность не все сделано. Верификация после регистрации подход не верный, верифицировать надо сразу после первого шага регистрации, не давая завершить регистрацию без верификации. Конечно, я допускаю, что у кого то еще нет мобильника (смешно даже), можно сделать под мобильным надпись с чекбокс вроде - от верификации отказываюсь, риск в плане безопасности осознаю. В таком случае - вопрос/ответ, но я бы принудительно оставил верификацию по SMS и все. Доп. услуги (последний билд) - ранее мы делали, чтобы MainID видел домены всех прикрепленных заказов - это отлично, то в последнем билде MainID видит все услуги, в т.ч. выделенные IP, что совсем плохо, так как выд. IP закрепляется за сервером. Только домены должны быть видны для MainID. Заказы 45951 и 51039 для проверки.

По SMS форма устроила. - По сути настройка - Если не заполнен вопрос-ответ не нужна, при настройке в любом случае если номер верифицирован, то предлагает SMS - ок, если не верифицирован, то предлагает вопрос-ответ. Для этого случая надо также на этой же стр. рекомендовать верификацию телефона. - Для остальных значимых действий система та же. - Если не заполнен вопрос-ответ на главной предлагать верификацию телефона, если заполнен также, так как в любом случае SMS более безопасно по сравнении с секретным вопросом. - Для новых заказов самое главное верифицировать телефон прямо при заказе как это сделать в большинстве сервисов. Также я просил ранее для Уведомления об истечении срока действия услуг: по SMS сделать отдельно настройку за какое кол-во дней рассылать, чтобы при большой базе не тратить много средств на рассылки.

Считаете, что с гос. учреждениями только мы работаем? Я так не думаю, да и требования у них у всех идентичны. Исходя из того, что это не индивидуальные изменения в коде, я считаю сумму не оправданной. По сути это единственное, что осталось доделать, чтобы биллинг мог в свои преимущества добавить полный документооборот для всех видов юр. лиц. Просмотр актов действительно из служебного реализован давно. Идей была в том, чтобы получить простую табличку за указанный срок вида: Номер заказа / Номер акта / итоговая сумма Номер заказа / Номер акта / итоговая сумма Номер заказа / Номер акта / итоговая сумма Номер заказа / Номер акта / итоговая сумма и т.д. от меньшей даты к большей. Получаем простой отчет для бухгалтерии, которой нет необходимости просматривать полную форму актов.

1. Сама идея, что биллинг дает заказать и оплатить перенос свободного домена выглядит странно, конечно ничего сильно страшного в этом нет, то тем не менее это стоит исправить ) 2. По CSF не все так гладко - IP банит, проверяет, но не разблокирует (см. скрин). Проверьте это на нашей системе - увидите сами. 3. Как то давно я просил сделать так, чтобы пользователь получал уведомление об истечении домена на e-mail, указанный не только для основного аккаунта, но и для домена. Это работает отлично, но только для доменов, которые не требуют пасп. данных. Если клиент меняет контактный e-mail, то для доменов, которые требуют паспортных данных, он меняется именно в пасп. данных (/admin/?mod=passport&thetype=domen&number=*****&userid=*****), а рассылка идет на e-mail, который указан на стр. самого домена. Таким образом клиент после смены почты все же получает уведомления на старый ящик. Вероятно, надо сделать так, чтобы при смене почты для доменов .su .ru .рф почта менялась и на стр. домена (/admin/?mod=domen&id=****)

CSF - возьмите любой IP заблокируйте на сервере, который я давал и попробуйте через служебное разблокировать - не работает.

Прошу также платно сделать возможность снятия отчета по актам юр. лиц, например, в служебном. Выбор периода, далее вывод: организация, номер акта от какого числа, сумма организация, номер акта от какого числа, сумма и т.д.

Расширение автозаказа не надо, в данном виде пока устраивает. По спецификации. Для клиентов, которые являются гос. учреждениями важно иметь стоимость услуг до оплаты. Все, что необходимо - это показ спецификации до оплаты/активации аккаунта на основе заказанных услуг. После активации номер и дату первой спецификации не менять.

По уведомлениям - делайте, а то главную чистить совсем не приятно. Выбор автоматический платеж или ручной. Если автоматический, то давать выбор платежей не оплаченных и по ним давать уведомлять. Если платеж ручной, то все как и прежде. По sms когда планируете сделать?

CSF будем проверять, если что отпишу. Клиенту то конечно домен надо зарегистрировать, но перенос свободного домена стоит исправить все же.

Клиент имеет возможность заказать перенос домена к нашему регистратору даже если он не зарегистрирован. Прошу исправить.

В дополнение к автозаказу хотелось бы иметь возможность указывать какие услуги для каких тарифов при заказе уже будут выбраны (клиент может снять чекбокс) и какие нельзя не выбирать. Чтобы было совсем красиво - рядом с такими услугами писать рекомендуем.

Отвалился CSF, при попытке разблокировать любой IP : Произошла ошибка при работе с модулем CSF. HTTP/1.0 200 OK Server: cpsrvd/11.38.2.3 Connection: close Date: Sun, 25 Aug 2013 09:06:58 GMT Content-type: text/html ConfigServer Security & Firewall - csf v6.33 csf - ConfigServer Firewall Allow IP address through the firewall and add to the allow file (csf.allow) Block IP address in the firewall and add to the deny file (csf.deny) Unblock IP address from the firewall (temp and perm blocks) Search iptables for IP address csf: v6.33 (Это табличка как в WHM, 4 позиции).

Если вместо ошибки получать надпись о том, что IP в игнорируемых, то это точно будет означать, что он есть там. Если клиент партнер или имеет только домены, то как ему заказать хостинг на юр. лицо? Сделать переход и тариф указать? Мне казалось, что должен быть и заказ активный не оплаченный с тарифом юр. лица. Можно ли привязать уведомления об оплате, если способ автоматический к платежу со знаком минус (не оплаченному) ? Т.е. при составлении уведомления давать выбор - ручной платеж или автоматический, если автоплатеж, то сделать жесткую привязку к неоплаченному платежу/счету. Частый случай, когда клиенты делают уведомления об оплате, которая уже прошла. Такое изменение позволит избежать не нужных уведомлений на Главной.

Сделайте при попытке блока IP из игнора вместо ошибки deny failed: 8.8.8.8 is in the ignore file /etc/csf/csf.ignore сообщение вроде - IP невозможно заблокировать, так как он в списке игнорируемых. Сделайте возможность аккаунтам PARTNER и DOMENREG возможность из аккаунта заказывать на юр. лицо.

По CSF: 1. Проверяем IP, который в csf.ignore - пишет, что не заблокирован. При попытке блока естественно: deny failed: 8.8.8.8 is in the ignore file /etc/csf/csf.ignore Если IP в csf.ignore, то логично написать, что он в списке игнорируемых и не давать кнопку блокировки. При попытке блокировать вместо вывода deny failed выводить, что IP в игнорируемых. При попытке разблокировать IP из ignore получаем IP Адрес 8.8.8.8 был удален на сервере из списка заблокированных. Не понятно, он же и не был заблокирован. Вывод проверки такого IP: Searching for 8.8.8.8... Chain num pkts bytes target prot opt in out source destination INPUT 3 0 0 ACCEPT tcp -- !lo * 8.8.8.8 0.0.0.0/0 tcp dpt:53 INPUT 4 0 0 ACCEPT udp -- !lo * 8.8.8.8 0.0.0.0/0 udp dpt:53 INPUT 5 0 0 ACCEPT tcp -- !lo * 8.8.8.8 0.0.0.0/0 tcp spt:53 INPUT 6 19 1352 ACCEPT udp -- !lo * 8.8.8.8 0.0.0.0/0 udp spt:53 OUTPUT 3 0 0 ACCEPT tcp -- * !lo 0.0.0.0/0 8.8.8.8 tcp dpt:53 OUTPUT 4 19 1245 ACCEPT udp -- * !lo 0.0.0.0/0 8.8.8.8 udp dpt:53 OUTPUT 5 0 0 ACCEPT tcp -- * !lo 0.0.0.0/0 8.8.8.8 tcp spt:53 OUTPUT 6 0 0 ACCEPT udp -- * !lo 0.0.0.0/0 8.8.8.8 udp spt:53 ...Done. 2. Проверяем IP, который в csf.allow или gallow. Получаем, что в списке разрешенных - отлично, но зачем кнопка удалить, ведь оттуда он не может удалить. При попытке удалить получаем, что удален из списка заблокированных, но его там не было, он же разрешенный был. Вывод: GALLOWIN 3 0 0 ACCEPT all -- !lo * 8.8.8.8 0.0.0.0/0 GALLOWOUT 3 0 0 ACCEPT all -- * !lo 0.0.0.0/0 8.8.8.8