Перейти к содержанию
Форумы

Список ожидаемых дополнений


admin

Рекомендуемые сообщения

Уведомления waiting на Главной я имел ввиду. Удалять их руками или запросом не так уж удобно. Я писал уже ранее об этом.

 

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

Не актуально: удалить. Если в процессе, то установить соответствующий статус и т.п..

 

Прикрепление доп. услуги к группе тарифов и не влияет на бонус. При оплате хостинга, где есть помесячная доп. услуга, которая прикреплена к не основной группе тарифов, не заносится в список платежей сам платеж за услугу, заносится только за хостинг, хотя сама сумма платежа верная.

 

Установил тарифу статус OffReg и добавил 1 месяц через админ-панель.

Платежи за доп. услуги в базу добавились. А в платеже по доп. услуге, закрепленной за сотрудником, - начислился бонус этому сотруднику (платеж закрепился за сотрудником автоматически).

 

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

 

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

 

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

 

Смена главного домена не закрыта секретным вопросом.

 

Добавлю.

 

При смене главного домена сбрасываются настройки:

 

 

DNS Settings

Enable DKIM on this account Enable SPF on this account

 

Видимо, баг cPanel, т.к. при изменении домена на API WHM отправляется следующий простой запрос:

 

"/xml-api/modifyacct","user=USER&domain=DOMEN"

Ссылка на комментарий
Поделиться на другие сайты

  • Ответов 4,1 тыс
  • Создана
  • Последний ответ

Топ авторов темы

Топ авторов темы

Изображения в теме

Теперь перестала работать даже стандартная схема с подарочными доменами. Регистрация у нас, платеж 0,01 есть, пробовал даже новый чекбокс ставить у домена - ничего, не считает. Варианты со сменой основного домена не проверить, так как вообще не работает. Прошу по возможность посмотреть поскорее.

 

Исправил для новой сборки.

 

Если теперь подарочный домен не привязывается к платежу, то при переносе клиентом домена из аккаунта в аккаунт можно переносить и вычет на новый аккаунт, если подарочный срок еще не вышел.

 

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

Сообщите, если это не так.

 

Как я понял, у недобросовестных клиентов появилась возможность переноса домена на соседний аккаунт и заказа moneyback на том аккаунте, на который получался подарочный домен, но домена в подарок на том аккаунте-то уже нет и соответственно вычета не будет. Может запретить перенос подарочных доменов?

 

DNS Settings

Enable DKIM on this account Enable SPF on this account

Думаю стоит внести изменения в тарифы с этими опциями, так как они крайне полезны. Также учесть их наличие при пересоздании и смене домена.

 

А разве если в тарифе в cPanel включены эти две ф-ии и аккаунт активируется по этому тарифу, то галочки в cPanel пропадают и ф-ии не работают? Вроде не должны же пропадать и все должно работать.

 

Обновил архив. Изменения в соотв. с ответами выше.

Ссылка на комментарий
Поделиться на другие сайты

По доп. услуге отпишу как доберусь до офиса на почту данные от нашей админки.

 

Регистрация доменов на юр. или физ. лицо даже у партнеров есть, т.е. по Вашей логике, если физ. лицу нужен домен на юр. лицо он должен сначала партнерский аккаунт зарегить? Где тут логика? Как я и писал любой регистратор разрешает регистрировать как угодно наши домены. Пусть клиент вводит инфу о себе, а на сл. страницу либо паспорт, либо данные фирмы. Это будет логично.

 

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

 

DKIM и SPF вообще в свойствах тарифа отсутствуют, думаю стоит эту тему оставить до тех пор пока сипанель не допилит кучу багов новой сборки, их там и правда много.

Ссылка на комментарий
Поделиться на другие сайты

DNS Settings

Enable DKIM on this account Enable SPF on this account

Эти параметры отсутствуют в свойствах тарифа, но присутствуют при создании аккаунта через WHM, при их включении в твиках панели при создании через WHM они стоят автоматически, при активации через биллинг - нет. Видимо надо передать еще какие то параметры API WHM.

Ссылка на комментарий
Поделиться на другие сайты

По доп. услуге отпишу как доберусь до офиса на почту данные от нашей админки.

 

Ошибка оказалась посложнее, чем группы тарифов или т.п. :) Исправил для новой сборки.

 

Регистрация доменов на юр. или физ. лицо даже у партнеров есть, т.е. по Вашей логике, если физ. лицу нужен домен на юр. лицо он должен сначала партнерский аккаунт зарегить? Где тут логика? Как я и писал любой регистратор разрешает регистрировать как угодно наши домены. Пусть клиент вводит инфу о себе, а на сл. страницу либо паспорт, либо данные фирмы. Это будет логично.

 

Если домен нужен на фирму, то на reg.php изначально надо указывать данные как на фирму, а оплатить потом по сформированному заказу можно будет не только о безналу.

 

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

 

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

 

DKIM и SPF вообще в свойствах тарифа отсутствуют, думаю стоит эту тему оставить до тех пор пока сипанель не допилит кучу багов новой сборки, их там и правда много.

 

Ок, ожидаем исправлений со стороны cPanel.

Ссылка на комментарий
Поделиться на другие сайты

DNS Settings

Enable DKIM on this account Enable SPF on this account

Эти параметры отсутствуют в свойствах тарифа, но присутствуют при создании аккаунта через WHM, при их включении в твиках панели при создании через WHM они стоят автоматически, при активации через биллинг - нет. Видимо надо передать еще какие то параметры API WHM.

 

Ага, в "create account" при ручном указании параметров аккаунта - они есть, а в "Add a Package" и "Edit a Package" - нет. Видимо, надо ждать исправлений от cPanel, или ее разработчики, возможно предполагают, что данные ф-ии нужно включать аккаунтам в ручном режиме, т.к. по умолчанию они должны быть обязательно отключены.

 

Архив обновил.

Ссылка на комментарий
Поделиться на другие сайты

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

 

Также не ясно вот что - для новых активаций подарочные домены будут помечаться сами - Это – домен в подарок, даже если есть домены с меньшим ID: ? Все существующие домены подарочные надо прогнать по базе с этим чекбоксом ?

Ссылка на комментарий
Поделиться на другие сайты

По доменам на юр. лиц - т.е. Вы имеете ввиду, что юр. лицо должно иметь возможно платить к примеру эл. деньгами ?

 

Да. Мы, например, принимаем такие платежи, но закрывающие акты по ним на имя организации не выдаем, т.к.платежи ведь от физ. лица, а не от организации.

 

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

 

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

 

Также не ясно вот что - для новых активаций подарочные домены будут помечаться сами - Это – домен в подарок, даже если есть домены с меньшим ID: ? Все существующие домены подарочные надо прогнать по базе с этим чекбоксом ?

 

Ничего прогонять не надо. По умолчанию домен в подарок - это домен на клиентском биллинг-аккаунте с самым маленьким ID.

Чекбокс "Это – домен в подарок, даже если есть домены с меньшим ID" появился для того, чтобы это умолчание изменять на какой-либо конкретный домен, ID которого больше, чем ID самого первого зарегистрированного с аккаунта домена.

Ссылка на комментарий
Поделиться на другие сайты

По юр. лицам я хотел позже поднять тему эту. Нужна опция разрешать или нет платить юрикам как физ. лицам. Там много есть недочетов и по формированию договоров и актов и т.п. Все напишу позже.

 

По реге домена физ. лицом на юр. лицо давайте реализуем платно, так как много кто просил уже из клиентов.

 

Проверил - платеж остается, но если нет самого домена, т.е. номер заказа домена черный (не активный), то вычет пропадает.

 

С чекбоксом ясно.

Ссылка на комментарий
Поделиться на другие сайты

По юр. лицам я хотел позже поднять тему эту. Нужна опция разрешать или нет платить юрикам как физ. лицам. Там много есть недочетов и по формированию договоров и актов и т.п. Все напишу позже.

 

Ок, распишите все в деталях. Самим будет интересно.

 

По реге домена физ. лицом на юр. лицо давайте реализуем платно, так как много кто просил уже из клиентов.

 

Так а что мешает клиентам производить заказ на reg.php, заполняя формы данных по юр. лицу с первой же страницы, а потом оплатить от имени физ. лица?

 

Проверил - платеж остается, но если нет самого домена, т.е. номер заказа домена черный (не активный), то вычет пропадает.

 

Да, действительно.

Домен должен быть в базе, чтобы скрипт по имени домена мог определить стоимость регистрации домена в конкретной доменной зоне и произвести вычет.

Значит домен удалять не надо, пусть висит в базе, а потом самостоятельно удалится по CRON по истечении оплаченного по биллингу срока.

Ссылка на комментарий
Поделиться на другие сайты

Тему с юр. лицами пока оставим на некоторое время, заодно и с заказом домена физ. лицом на фирму.

 

Если переданный домен не удалять, то клиент будет его видеть и путаться. Часто клиенты передают другому партнеру регистратора домены. Может отдельный статус ввести. Домен в биллинге есть, но к примеру, не активен.

Ссылка на комментарий
Поделиться на другие сайты

Как вариант, можете перегонять этот домен на свой клиентский биллинг-аккаунт :)

Тогда надо функцию автопередачи домена на указанный аккаунт :) Через панель клиента с ответом не сильно удобно.

Можно в админке клиента, в домене рядом с удалением "передать". Где нибудь в настройках забить номер аккаунта для этой функции.

Ссылка на комментарий
Поделиться на другие сайты

При добавлении ф-ии была добавлена и настройка к ней:

Настройки -> скрипт -> секретный вопрос -> требовать при -> переносе домена между аккаунтами

Ссылка на комментарий
Поделиться на другие сайты

При добавлении ф-ии была добавлена и настройка к ней:

Настройки -> скрипт -> секретный вопрос -> требовать при -> переносе домена между аккаунтами

Отлично.

Ссылка на комментарий
Поделиться на другие сайты

Есть небольшое предложение. Для большей наглядности на главной разделить уведомления от клиентов от -

1. не выданных услуг

2. не активированных по какой то причине аккаунтов

3. не зарегистрированных по какой то причине доменов

4. заявок партнерских выплат

 

Например, отдельной небольшой табличной сверху перед началом таблицы уведомлений.

Ссылка на комментарий
Поделиться на другие сайты

По идее, администратор должен иметь доступ ко всем этим позициям и в порядке очереди решать появившиеся задачи.

Плодить кучу таблиц на главной странице не считаю нужным.

Ссылка на комментарий
Поделиться на другие сайты

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

И как я понял теперь записи более свежие сверху (за искл. главной), тогда стоит в отображении платежей в тикете тоже поправить, а то в самих платежах уже по новой схеме, а в тикете по старой.

Ссылка на комментарий
Поделиться на другие сайты

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

 

Как именно разделить уведомления? Цветом? В разные таблицы? или как-то еще?

Если цветом, то радуга получиться с учетом того, что сейчас каждая 2-ая строчка итак подсвечивается иным цветом, тогда эту подсветку каждой 2-й придется убирать.

 

И как я понял теперь записи более свежие сверху (за искл. главной), тогда стоит в отображении платежей в тикете тоже поправить, а то в самих платежах уже по новой схеме, а в тикете по старой.

 

Исправил для сборки, которую выложу в течение 5-и минут.

Ссылка на комментарий
Поделиться на другие сайты

Думаю логично под табличкой сводной

Добро Пожаловать в BPanel v3.0 Release

 

сделать табличку с доп. услугами, не активированными доменами и аккаунтами, т.е. записи, имеющиме одну строку на главной. Пусть она имеет такой же вид как и все на Главной, просто записи слепленные вместе, просто между не ушедшими услугами/доменами/аккаунтами сделать отступ, а далее уведомления об оплате. Цвет менять не нужно.

Ссылка на комментарий
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

×
×
  • Создать...