баг-лист интранет-портала

24 views
Skip to first unread message

Александр Дружков

unread,
Jul 30, 2010, 9:53:02 AM7/30/10
to Внедрение ИТ в обществе
Обнаруженные баги и недочеты в работе интранет-портала. Можно
присылать свои.

ГЛОБАЛЬНО:
- Перенос пользователя между отделами: как поступать с переносом
привилегий?
- Окончательно перейти на utf-8 версию
- Для гостей сессии не создаются, хотя в перспективе возможны
компоненты, где могут работать даже гости (их нужно будет различать по
номеру сессии)
- Пользователи: в принадлежности к отделам сделать связку "один ко
многим", чтобы один пользователь мог входить сразу в несколько отделов
(это решило бы проблему доступа к компонентам)
- Убрать везде в SQL-запросах вставку автоинкрементных полей.
- во всплывающих окнах бывает, что текст вылазит за пределы самого
окна

ЭЛЕКТРОННАЯ ОЧЕРЕДЬ:
- более тонкое разграничение записи в разные окна в пределах одного
отдела
- добавление заявителей - блокировать выбор действия, если действие
только одно
- возможность нормально конфигурировать график работы окна ( в админке
возможность уже заложена - скрипт otdel.php )
- кнопки "вперед"-"назад" в дате, чтобы можно было шагать по дням
- было бы неплохо переделать всю таблицу на div-ы. Во-первых, чтобы
границы таблиц не ездили, во-вторых, чтобы было не много мелких ячеек
с одним заявителем, а одна вытянутая
- не влазит на малоразмерные мониторы
- в добавлении промежутка времени (праздничные дни) нет проверки на
корректность промежутка времени. Комментарий к записи нигде не
отображается. При изменении окна нет функции reloadPage
- в statistic вынести все в отдельный js-файл
- если в окне меняется график работы, то нужно сделать, чтобы записи
за предыдущие дни отображались нормально (может получиться так, что
неактивные ячейки станут активными, а активные - наоборот,
заблокируются)

АДМИНПАНЕЛЬ:
- в добавлении привилегий не показывать тех пользователей, кому уже
даны привилегии. Также показываются те, чей профиль заблокирован
- не полностью очищаются глобальные привилегии при удалении
пользователя
- добавление пользователей - если уже есть с таким логином - не
выводится предупреждение, а пишется, что "пользователь добавлен"
- постоянно сыпет какую-то ошибку "/var/www/admin/<"

ЭЛЕКТРОННЫЕ ЗАЯВКИ:
- блокировать повторные нажатия кнопки отправки заявки
- возможно, после отправки заявки следует закрывать форму для
отправки, чтобы человек явно видел, что его заявка отправлена
- сделать сброс двухэкранного режима при выходе из системы
- если неустранимо, то тоже нужно вводить метод решения проблемы
(нелогично)
- если неустранимо, то отображать каким-то другим цветом в общей
статистике

ТЕЛЕФОННЫЙ СПРАВОЧНИК:
- возможность просматривать заявки о неточностях в справочнике и
ставить отметки о выполнении (аналогично электронным заявкам)
- разделение на страницы, если в одном отделе слишком много
сотрудников
- цвет галочки меняется в зависимости от степени заполненности
профиля. Либо миниатюрный прогресс бар.

Iskam

unread,
Aug 24, 2010, 6:21:00 AM8/24/10
to Внедрение ИТ в обществе
Пять копеек про электронные заявки:

1. Зарублена возможность использовать кириллицу в логинах. Считаю,
зря, тем более сделать то легко, вместо "/[^A-Za-z0-9_]/" пишем "/[^A-
Za-
z0-9абвгдеёжзийклмнопрстуфхцчшщьыъэюя_АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЫЪЭЮЯ]/"

2. при просмотре заявки специалистом ремонтного отдела видим
<td valign="top" class="normal"
style="border-bottom: 1px solid #ccc; background: #ecf2f4;">
<b>'.$zayavka_info['short_name'].'</b>
<br /><br />
<b>тел.</b> '.back_convert($zayavka_info['phone']).'
<br />
'.back_convert($zayavka_info['person']).'
<br /><br />
<b>инв. No.</b> '.back_convert($zayavka_info['inv_nomer']).'
</td>
а я, например, поотключал проверку ввода этих полей, кроме номера
телефона, в заявке, так как считаю, что главное здесь - пользователь
оставивший заявку. А имени пользователя из global_users мы в списке
как раз и не видим. Я к чему это всё... К тому, что меня бы, как
пользователя, просто бесила бы необходимость писать своё имя и\или
фамилию в "контактном лице", при том, что я под своей же фамилией
залогинен и вообще то в базе есть моё полное имя и мой отдел (это на
случай однофамильцев или полных тёзок).
А вот контактное лицо (не себя, а своего помощника, секретаря и т.п.)
имеет смысл указывать уж каким нибудь особо занятым главначпупсам,
которые хотят освободить себя от общения с поддержкой. С другой
стороны, по опыту знаю, такие граждане очень врядли вообще будут какую
то форму заполнять. Проще позвонить или поручить тому же секретарю.

3. Очень плохо то, что отсутствует возможность написать комментарий к
заявке специалисту, которому она поручена. По сути, спец может либо
выставить статус Решено\Нерешаемо, либо спихнуть заявку коллеге.
Обязательно нужен комментарий и при решении - общее описание пути
решения. Вот тут я сам не разобрался как самостоятельно допилить этот
функционал (я просто совсем не программист и даже в простом коде не
всегда могу сориентироваться), поэтому обращаюсь к сообществу, - если
кому не лень, - подскажите как реализовать, тем более, что в самой
базе remont_zayavka есть поля sposob и comment - это ведь то о чём я
говорю, верно?

Iskam

unread,
Aug 24, 2010, 6:47:54 AM8/24/10
to Внедрение ИТ в обществе
собственно, с последним пунктом связана ещё одно необязательное
неудобство для пользователя. в случае, когда, мы не пишем в
remont_zayavka автора заявки, мы вынуждаем пользователя помнить номера
всех своих заявок для того, чтобы их контролить. и нет очевидной
возможности просмотреть все свои заявки.

Alexander Druzhkov

unread,
Aug 30, 2010, 6:19:25 AM8/30/10
to nova...@googlegroups.com
Iskam,

система заявок писалась, исходя из реалий нашего собственного отдела.
Поэтому сделано так, что логиниться не нужно, и контактные данные
заполняются руками. У нас это оказалось проще, чем объяснять людям про
еще один логин-пароль :-) .

---------------


3. Очень плохо то, что отсутствует возможность написать комментарий к
заявке специалисту, которому она поручена. По сути, спец может либо
выставить статус Решено\Нерешаемо, либо спихнуть заявку коллеге.
Обязательно нужен комментарий и при решении - общее описание пути
решения. Вот тут я сам не разобрался как самостоятельно допилить этот
функционал (я просто совсем не программист и даже в простом коде не
всегда могу сориентироваться), поэтому обращаюсь к сообществу, - если
кому не лень, - подскажите как реализовать, тем более, что в самой
базе remont_zayavka есть поля sposob и comment - это ведь то о чём я
говорю, верно?

---------------

Да, sposob - это способ, которым была решена заявка. comment - как
задумывалось (но не было реализовано), комментарии по ходу выполнения.
Если железобетонно решили внедрять систему у себя - можно попробовать
добить этот вопрос (пишите мне на мыло).

По остальным замечаниям согласен, внес в свой список на выполнение.

Reply all
Reply to author
Forward
0 new messages