Обзор:
Нужно запилить отдельный блок на странице создания ордера, в котором будет написано, сколько по этому ордеру должен будет платить кастомер за подлючение и в месяц.

Critical:

• Это таблица, которая имеет хедер (onetime, monhtly), строчку installation fee, строчку, отвечающую за продукт и строчку total.
• Таблица должна лежать в отдельной форме и апдейтиться ajax при смене продукта.
• При сабмите installation fee должна сториться в ордере (это накладывает ограничение на формы - форма таблицы должна лежать в editform).
• Total должен апдейтиться сразу при изменении поля installation fee (не по Enter, а по onChange)

High:

• Блок должен быть виден только на подключение (c:if).
• input поле instalation fee должно иметь валидацию - сообщение об ошибке должно быть над таблицей (p:messages). Ордер не должен сабмититься, если instalation fee не введено/содержит не только число.

Normal:

• Нужно использовать бутстраповскую верстку, чтобы поместить таблицу справа от заполняющихся полей.
• Если что-то из текстовых полей = 0 - вместо числа пишется прочерк, но только не в total monhtly.
• Таблица по-возможности должна быть симпатичной, в нашем общем отвратительном стиле, но при этом уж точно не striped. И без внутренних ребер таблицы. Пример я показывал.

Общий план - просто ордера для кастомера должны создаваться только на создание, отключение должно производиться из страницы кастомера, таблицы products.

• Сделать новую табличку products на страничке кастомера. В колонках - общая инфа, главное - имя продукта и последней колонкой кнопка на отключение.
• Соответственно на страничке создания ордера поле типа ордера (connect/disconnect) должно быть засерено и показывать нужный тип в зависимости от ситуации.
• При подключении продукта добавляется строчка в PRODUCTS_CUSTOMERS: customer_id, product_id, pool и extra_id. Если у продукта используется какой-то ресурс (ip/phone), то тип должен писаться в пул, а его id в extra_id
• Ордер на отключение продукта должен работать. Соответственно если есть пул, то надо высвобождать ресурс (методы есть)

Основная задача: создать wsdl-файл, который будет определять доступные методы вебсервиса

1. Прочитать про restful и soap вебсервисы и быть готовым рассказать в чем разница и что лучше

2. Разобраться, как генерить wsdlку, которой будут генериться все исходники для клиента и сервера

3. Продумать, какие методы необходимы для биллинга (смотри структуру стабы в другой ише), навскидку:

   • addCustomer
   • removeCustomer
   • addProduct
   • removeProduct
   • getBalance
   • withdrawMoney

   Продумать, какие параметры должны передаваться и как их назвать

4. Cгенерить ее, создать и клиента, и сервер в soapui

5. Закоммитить и wsdlку, и проекты soapui

* Имеет смысл запретить редактирование ордера при всех статусах, кроме new.
Причина: при прогоне ордера добавляются/удаляются продукты, аллокейтятся ресурсы и так далее. Менять завершенный ордер бесполезно, находящийся в процессе - неправильно.

• При отмене ордера следует избегать проблем типа: продукт был добавлен, но в биллинг не добавился, ресурс был заалокейчен но продукт не был добавлен и так далее. Решение: добавлять продукт в CUSTOMERS_PRODUCTS сразу при успешном биллинге в той же авто-таске. в первой таске ресурс ставить этому кастомеру со статусом hold, во второй active. При нажатии cancel должен отрабатывать метод, который отпустит тот hold ресурс

Имеет смысл переписать документацию в wiki проекта.

• Оставить старую документацию с подписью [archive], главную страницу пометить так же и сделать главной страницей новую со ссылкой на старую главную
• Написать на основе старых новые fds и ui документы; главное требование - официальный стиль, как в оригинале
  • FDS: описать все существующие возможности продукта
  • UI: описать все экраны продукта, залить новые скриншоты (вроде их не обязательно хранить в репозитории, как это делал я)
• Поправить правила разворачивания проекта, т. к. появилась стаба.

Замеченные проблемы:

• Нужна кнопка обновления баланса для конкретного кастомера
• Нужна кнопка для мгновенного сниманияя денег со всех клиентов в стабе

Я здесь буду писать некоторые общие замечания, а в комментариях конкретные места, которые нужно исправить.

1. Не используйте табуляции - используйте 4 пробела. Это упростит разруливание конфликтов и мержи.
2. Пользуйтесь форматированием кода в вашей IDE. Придерживайтесь одного стиля.

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

3. Не используйте if/else без фигурных скобок. Иначе есть шанс ошибиться и, если код в дальнейшем изменится так, что в теле if будет несколько строк вероятность ошибки очень велика.
4. Не пишите new Long(5), new Integer(4) и т.п. Умные ребята из Sun (уже из Oracle) сделали для вас умный autoboxing с кешированием и барышнями. Это также относится и к String, Byte, Short, ...
5. Длина строки не более 120 символов - иначе не влезает в экран и читать неудобно == не понятно.

*Пролистайте какой-нибудь коротенький codestyle tutorial по Java, например, http://google-styleguide.googlecode.com/svn/trunk/javaguide.html (здесь вам нужно далеко не все)

Связать методы в стабе с методами в основном проекте

Сейчас есть две автотаски, которые надо реализовать:

1. Allocate resources
2. Billing

$resource = {$static_ip, $phone_number}

1. Allocate resources
   Логика такая - есть хардкоженная табличка всех $resource, и они либо на кого-то асайнятся, либо не заняты. Соответственно надо протаскивать параметр ордера order_type чтобы понимать, connect или disconnect. Если есть что заасайнить - асайним и отдаем true, если нет, то false.
2. Billing
   На данный момент обещана стаба со всеми реализованными методами. Основная задача - вместе с Ильей научиться коннектиться с стабе из основного проекта. Ну и в рамках этого тикета реализовать запросы на снятие денег и добавление/удаление продуктов (в зависимости от типа ордера). Продукт из ордера ты можешь зохавать, а one-time price пока нет, так что хардкодим

Надо бы переехать на новый primefaces 5.1

Причины:

• как я понял, много вещей заимствовано из бутстрапа (например грид) => можно отказаться от бутстрапа в пользу jsf-решений
• есть новые ui компоненты, которые позволят сделать наш ui менее мерзким (вот InputSwitch вместо чекбокса например)
• стабильность скорость блаблабла

Когда создается ордер, обязательными параметрами являются вот эти:

Хотя на самом деле в бд их больше:

Соответственно залить кастомера, не заполняя всех обязательных полей из бд невозможно. Нужно сделать так, чтобы в бд обязательными были только поля, которые обязательны в ui.

Также проверить, возможно ли получить такую же багу при создании ордера

Имеет смысл выбросить дампы базы куда-нибудь из корня репозитория, или удалить вообще. Если потребуются, из старых коммитов подтянем.

Общая задача: править явные неточности в названиях, готовить систему к интеграции со стабой.

1. Изменить названия таблиц на множественное число и прописать в сущностях новые имена таблиц, при этом названия сущностей должны быть в единственном числе
2. Изменить таблицу products:
   • добавить ежемесячную плату (monthly_price)
   • поменять название колонки на baseline_price на onetime_price.
   • изменить название колонки properties на pool или более подходящее
3. Почистить бд (при этом желательно экспортировать себе всю бд, чтобы в случае чего восстановить):
   • посмотреть, какие из дублирующихся таблиц лишние и удалить их. Между таблицами markets_customers и marketscustomers приоритет отдается первому названию.
   • удалить все таблицы, заканчивающиеся на "_history"
   • удалить таблицы, относящиеся к биллингу
4. Изменить в стейт-машине engineer на technitian
5. Фрейм добавления/изменения ордера:
   • добавить Installation Fee - и при создании, и при изменении. Нужно, чтобы он читался так же и там же, где и все остальные параметры (в каком-то jsf бине должно быть такое поле, геттер и сеттер)
   • изменить название поля Employee на Authorized by
   • в табличке выбора продукта из каталога - проставить колонку с ценой в месяц и хедер (названия колонок с ценой - One-time и Monthly)

• Поправить wsdl'ку с учетом комментария в #8

Итак, проект crm4telecom_stub играет роль биллинговой системы и в данном случае является сервером soap-вебсервисов. Соответственно на данном шаге нужна реализация всех методов, которые предоставляет вебсервис. Это методы:

• addCustomer
• addProduct
• removeProduct
• getBalance
• getStatuses

Уже есть: таблицы бд, сущности бд. Надо:

• создать пакет .ejb и запилить CustomerManager. Прописать методы, соответствующие таковым у вебсервиса.
• подобрать wsdl'ку, сгенерить по ней пакет классов для сервера, в обработке респонсов прописать логику для вызова методов из CustomerManager.
• подключить в качестве клиента soapui и попробовать работоспособность (там, где обычно логи глассфиша при ошибке, можно выводить любые сообщения через System.out.println - так можно палить, что происходит, не подключая нормальный логгинг)
• посмотреть в настройках сервера, как задеплоить твою стабу на другой порт, сделать это и написать по этому поводу мануал (или написать в мой по поднятию проекта)

1. Добавить приоритеты и последнюю версию требований в репозиторий
2. Нарисовать схемы экранов про заявки
3. Поискать редактируемую версию uml-диаграммы БД

открываешь страницу Add Order в reference selector должны при вводе customer появляться подсказки не только по номеру но и по имени и фамилии
Скорее всего она произошла из-за переименования таблицы или столбца

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

Как я это вижу: нам нужна страничка на jsf, которая будет содержать табличку с колонками

• user_id
• input поле для количества денег

Что важно:

• изначально табличка должна подтягиваться из базы и обе колонки должны быть заполнены
• необязательно именно табличку - можно просто добавлять теги в цикле, тем или иным образом, главное чтобы было юзабельно
• как только input становится inactive, счет должен валидироваться (что он вообще число) и сториться
• справа от двух колонок надо оставить место для сообщений валидации (как у существующих фреймов для новых кастомера/ордера). ну и сообщение должно быть. это делается средствами primefaces - даже проще, чем у нас реализовано. либо сделать маску и required - тогда валидация не нужна.
• предположительно страниц будет несколько, так что было бы неплохо загнать хедер в темплейт, как это реализовано в проекте.

Сейчас стейт-машина работает так: есть emum'ы OrderStatus и OrderStep. Первый говорит об общем статусе заявки (NEW, OPENED, CLOSED, CANCELLED), второй говорит о текущем шаге процесса. Первый шаг и статус выставляются руками, дальше каждый шаг имеет метод nextStep(flag) и поле doneStatus - cтатус, который выставляется при завершении данного шага. Все таски по своей сути имеют тип юзертаски - таски, которая должна прогоняться при участии пользователя. Это таски PRE_CONFIRM, SEND_TO_TECH_SUPPORT, TECHNITIAN_APPOINT, POST_CONFIRM. Юзерстори такая: девочка сидит за телефоном, ей поступила заявка подлючить чуваку интернет. Она создает новый ордер, заполняет его. Первая таска - PRE_CONFIRM - подтвердить, что чуваку это надо. Потом на выбор - либо мы отправляем ишу тех саппорту и они разрешают ему инет на своем ПО, либо отправляем ишу технишану и он приходит, после того как он справился проставляем эту таск сделанной. Последняя - POST_CONFIRM - подтвердить, что клиент доволен.

• Теперь процессинг должен проходить так:
  • PRE_CONFIRM (USER_TASK), doneStatus = NEW
  • SEND_TO_TECH_SUPPORT (AUTO_TASK), doneStatus = OPENED
  • NEED_POOL_RESOURCE?
    • YES. ALLOCATE_RESOURCE (AUTO_TASK), doneStatus = OPENED
  • NEED TECHNITIAN?
    • YES. TECHNITIAN_APPOINT (USER_TASK), doneStatus = OPENED
  • BILLING (AUTO_TASK), doneStatus = OPENED
  • POST_CONFIRM (USER_TASK), doneStatus = CLOSED
    ALLOCATE_RESOURCE или BILLING могут падать - первый на том, что нет ресурса (ip или phone), второй на том, что юзеру не хватает денег.
• Соответственно на вход оркестратора теперь должны приходить два параметра: нужен ли технишан, нужен ли ресурс и какой ресурс.
• Если таска дает ошибку - нужно не переходить на следующий шаг а оставить как есть, но статус поставить в Error и название кнопки Next Step заменить на Try Again - тогда при нажатии он снова попробует прогнать этот шаг, а статус сам сменится при переходе на следующий шаг.

Как я вижу дизайн:

• Вынести классы OrderStatus, OrderStep и TaskType в пакет .orchestrator
• Добавить статус ERROR в OrderStatus
• Сделать enum типа TaskType = {AUTO_TASK, USER_TASK}
• Сделать интерфейс Task (поле TaskType, методы Task(String name, Map parameters), getName()), классы AutoTask (метод run()) и UserTask.
• В OrderStep теперь вместо полей label и doneStatus будет поле task, task будет создаваться в конструкторе записи enum.
• У последнего шага nextStep должен возвращать null.
• Создать класс Orchestrator, который будет инкапуслировать всю логику со статусами и сменой шага. Метод toNextStep(), который делает у существующего шага nextStep(), если null то выставляем статус CLOSED, иначе OPENED. Если попалась автотаска, то выполняем метод run. Если run вернул error, то переводим статус в ERROR.

Написать DDl скрипт,создающий базу данных согласно диаграмме.
Написать скрипт создание заказчиков ( 2 экземпляра).
Подумать и реализовать JPA соотвествующй данной базе данных.

Make a header for product selection menu

• Создать в проекте папки для DML и DDL скриптов
• Создать бины, работающие с сущностями бд. Методы должны принимать на вход данные, совпадающие с таковыми для веб-форм (если есть страница "добавить клиента" с полями "имя", "фамилия", то метод должен быть createClient(String firstName, String lastName)). Реализовать для всех требований уровня Critical.

INTRO.
@BeforeClass - выполнется перед инициализацией класса (статики)
@before - выполняется перед созданием инстанса, т.е. перед каждым тестом (методом-тестом)
@afterclass и @after - после окончания всех тестов в классе и кадждого теста соответственно

Разбор ошибок на примере CustomerManagerTest:
a) Я не уверен, но на сколько я понимаю аннотации stateless и ejb там не нужны
b) Писать ничего в консоль не нужно. Тест либо проходит, либо падает, никто не будет читать его выхлоп вручную, на то он и автотест.
c) Возвращать null как объект для проверки в общем случае плохо. Нужно создать какой-то объект заглушку и возвращать его
d) Пустые методы не нужны
e) Naming у тестов совершенно не говорит о том, что проверяет тест + на каждый кейс - отдельный тест. Например:
public void testCreateCustomer_shouldThrowNullPonterException_whenCustomerIdIsNull()
f) Передавать явно константу (-1) не стоит - заведите для нее private static поле
g) getCustomer принимает Long. Если уж делать каст, то к Long, а не к long, чтобы не порождать лишний boxing/unboxing, а лучше пользоваться строковыми литералами: -1L - long, 0.02F - float, 0.15D - double (обратите внимание на upper case, иначе с long'ом могут проблемы - он похож на 1)
h) На exception проверять надо так: @test(expected=NullPointerException.class)

Надо сделать шедулер, который раз в день в определенное время снимает деньги у всех кастомеров в зависимости от купленных ими продуктов. По запросу "java scheduler" вторая ссылка (хотя первая вообще на javadoc - красота):

http://stackoverflow.com/a/7814149

(да-да, именно шедулер, никаких таймеров)

Я думаю, что

• в ejb должен быть метод типа "снять у всех кастомеров денег прямо сейчас если можно" в котором вся логика написана на sql.
• те две строки по ссылке должны ссылаться на класс типа Runnable (или экземпляр класса) который должен вызывать тот метод из ejb.
• те две строки должны вызываться при разворачивании приложения один раз, чтобы все работало.

В результате шедулер должен:

• Снимать деньги за все продукты одновременно
• Если чувак уходит в минус, то выставлять ему статус blocked
• Если чувак ушел в минус, то больше с него не снимать
• Если у чувака статус типа unplugged, то тоже с него не снимать, даже если у него есть деньги

статусы должны быть прописаны в enum, как в основном проекте
если считаешь, что надо статусы по другому назвать - welcome

хм, надо кстати запилить в wdsl метод setStatus(customerId) на случай если ты хочешь отключить кастомера из основного проекта

Общая задача: создать проект стабы и бд для него

1. Создать новый проект в корне репозитория, назвать его crm4tlecom_stub

2. Зайти стандартными креденшелами на бд и создать там нового юзера с именем crm4telecom_stub

3. Создать под ним таблички:

   • customers, колонки:
     • customer_id (primary key)
     • balance
   • products, колонки:
     • product_id (primary key)
     • onetime_price
     • monthly_price
   • customers_products, колонки:
     • customer_id (foreign key на customer_id из customers)
     • product_id (foreign key на product_id из products)

   Все это можно делать по аналогии с тем, что уже есть.

4. Залить кастомеров и продукты из соответствующих таблиц.

5. Сгнерить в netbeans сущности по этим таблицам, и они должны быть в единственном числе

Через библиотеку Primefaces реализовать веб-представление следующих страниц:

1. Главная страница
2. Работа с клиентами:
   2.1) список клиентов
   2.2) информация о клиенте
   2.3) редактирование информации о клиенте
3. Работа с заявками:
   3.1) список заявок
   3.2) информация о заявке
   3.3) редактирование заявки

Связать веб-формы с API для БД.

Существуют некоторые проблемы с allocate resource - провижининг падает на этом шаге.
Возможные причины:

• кривые руки
• отсутствие пула ресурсов в бд
• ????

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