При очистке конфигурации блока в плате VE-02 продолжают отображаться пользовательские данные

[roman_zhur]

В блоке имеется плата VE-02. После очистки конфигурации блока (вкладка "разное" -> Очистить конфиг -> да -> да) и перезапуска swd в плате VE-02 продолжают отображаться настроенные пользователем КО установленных субмодулей до перезагрузки платы VE-02.
Ожидалось, что при очистке конфигурации блока стираются все данные.
Предлагаю сделать так, чтобы при очистке конфига в плату записывались пустые данные по умолчанию.

В конфиг файлах после очистки нет данных про КО, однако прописанные до очистки URI продолжают отображаться в веб-интерфейсе платы VE-02.
test1.xml - изначальный конфиг
1.png - КО в этом конфиге
config_after.xml, config-export-VE-02_after.xml - конфиг файлы после очистки
2.png и 3.png - скриншоты КО после очистки конфига и перезапуска swd

Версия sw: 1.0-r2586
VE-02 Ревизия прошивки 63

[alx]

Replying to roman_zhur:

Ожидалось, что при очистке конфигурации блока стираются все данные.

Во-первых, я не очень понимаю, при чем тут sip_ua и плата VE-02. Конфиг-файл блока находится в плате SW-01, а не в плате VE-02, функция его очистки также реализована в плате SW-01 и к плате VE-02 прямого отношения не имеет.

Во-вторых, после очистки конфиг-файла конфиг-файл становится таким:

 <?xml version="1.0" encoding="UTF-8"?>
<config/>

Я в нем не вижу никаких данных. У тебя не так?

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

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

В конфиг файлах после очистки нет данных про КО,

То есть действительность совпала с твоим ожиданием. В чем же тогда заключается баг? Обычно тикет типа "баг" создают, когда поведение аппаратуры не совпадает с ожидаемым... :)

однако прописанные до очистки URI продолжают отображаться в веб-интерфейсе платы VE-02.

Не понимаю, какое отношение канальные окончания платы VE-02 имеют к тому, о чем ты написал выше. Определись, пожалуйста, на что ты "жалуешься". Если жалоба на функцию очистки конфига, то тикет следует создавать в проекте sw-01, а не sip_ua. Если же жалоба на работу платы VE-02, то опиши, пожалуйста, что ты ожидал от платы VE-02, и чего не получил в действительности. Я пока так и не понял, в чем по-твоему состоит баг, на который ты жалуешься.

[alx]

Replying to roman_zhur:

config_after.xml ... - конфиг файлы после очистки

Верно ли я понял, что ты в веб-интерфейсе SW-01 на вкладке "Разное" кликнул "Очистить конфиг", затем в появившемся диалоге кликнул "Да", после чего в плате SW-01 оказался конфиг-файл, который приложен к этому тикету под именем config_after.xml, то есть получился не пустой конфиг, который я привел в comment:1?

[roman_zhur]

пересоздам тикет в другой теме

[san]

Переоткрою тикет, т.к. вопрос всё-таки касается платы VE-02, а не SW-01
Пользователь записывает в плату пустую конфигурацию, но после записи, видит в окончаниях субмодулей платы VE-02 старые настройки. Это немного дезориентирует пользователя, т.к. он привык, что настройки плат при записи пустой конфигурации возвращаются в дефолт. При первой установке субмодуля пользователь видит пустые настройки(дефолт) и при удалении конфигурации он тоже ожидает получить пустые настройки.
Ко мне уже несколько раз обращались пользователи, чтобы спросить нормально ли это, что при сбросе конфига, настройки окончаний субмодулей VE-02 не становятся пустыми. Т.е. с точки зрения пользователей это не интуитивно.
Предложение в том, что при записи пустой конфигурации в настройки окончаний субмодулей, возвращать настройки окончаний субмодулей в дефолтное состояние, как если бы они были первый раз вставлены в плату.

[alx]

Replying to san:

Переоткрою тикет, т.к. вопрос всё-таки касается платы VE-02, а не SW-01

Насколько я вижу, предложение тикета касается того, какие данные записываются в плату VE-02 по умолчанию (при пустом конфиг-файле). Данные в плату VE-02 записывает именно SW-01, сама VE-02 никак не может влиять на то, какие данные в нее запишет SW-01 - у VE-02 в данном случае пассивная роль, а активная - у SW-01.

Изначально я недостаточно внимательно прочитал тикет и ошибочно понял так, что автор жалуется на то, что конфиг-файл не очистился (к тикету приложен совсем не пустой конфиг якобы после очистки), и поэтому я посчитал это багом SW-01. Однако предложенное улучшение все-таки также более касается SW-01 чем VE-02.

Как бы то ни было, раз переоткрыт дуюлирующий тикет, я вынужден продублировать здесь то, что уже написал в проекте sw-01. Я рассмотрел сделанное автором тикета предложение, но принял решение его отклонить по следующим причинам:

Во-первых, пустая строка не является валидным значением SIP URI. Записывать в плату заведомо невалидное значение параметра я не считаю хорошей идеей.

Во-вторых, автор не аргументировал, почему он считает свое предложение улучшением - не написал, почему если в URI канального окончания платы VE-02 записать пустую строку (что, как я написал выше, является заведомо невалидным значением) аппаратура станет лучше. Я сам улучшения в этом не вижу. Канальное окончание с пустым значением URI заведомо не будет работать.

При первой установке субмодуля пользователь видит пустые настройки(дефолт)

Это не совсем так. Дефолтом для плат VE-01 и VE-02 является отсутствие канальных окончаний. То есть результатом применения пустого конфига должно было бы быть исчезновение канальных окончаний, а вовсе не канальное окончание с пустой строкой в качестве значения URI, как предлагает roman_zhur (здесь он этого не написал, он уточнил это в ​дублирующем тикете в проекте sw). Именно так и вела бы себя плата VE-01. Однако в плате VE-02 каналы 255 и 256 - особенные. Пользователь не может по своему желанию создавать или удалять (!!!) на них канальные окончания, так как эти канальные окончания работают с установленными на плате модулями. Это сделано как раз для того чтобы не дать пользователям сделать ошибку (создать канальное окончание не того типа, которое не может работать с имеющимся на плате модулем).

и при удалении конфигурации он тоже ожидает получить пустые настройки.

Это ожидание ошибочно, так как пользователь (в данном случае roman_zhur) не записывал в плату настройки канального окончания FS01 с пустой строкой в качестве значения конфигурационного параметра uri.

Ко мне уже несколько раз обращались пользователи, чтобы спросить нормально ли это, что при сбросе конфига, настройки окончаний субмодулей VE-02 не становятся пустыми. Т.е. с точки зрения пользователей это не интуитивно.

Пользователи и не должны руководствоваться своей интуицией (хотя бы потому что у разных пользователей она может быть разной). :) Работа аппаратуры должна быть описана в руководстве по эксплуатации. Вот я сейчас специально посмотрел и обнаружил, что там (в РЭ) есть некоторый пробел: что канальное окончание создается автоматически там написано, а что его нельзя удалить - нет. Наверное в этом и кроется причина подобных недоразумений. Я думаю, стоит порекомендовать разработчику РЭ добавить какие-то примечание о том, что эти два специальных канальных окончания пользователь не может удалять.

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

Ну, вообще-то, нет, этого roman_zhur не предлагал. Это уже какая-то твоя расширенная интерпретация. :)

[san]

На мой взгляд, всё-таки довольно странно выглядит(с точки зрения пользователя), что пользователь не может удалить данные которые он ввёл. Он видел что до введения им данных в настройках окончания было "пусто" и кажется непонятным почему после удаления конфига не стало опять пусто.

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

Можно сделать интерфейс интуитивным для большинства пользователей, а можно неудобным и неинтуитивным для всех))) и даже если описать всё в РЭ сомневаюсь что пользователям понравится.

Алексей, кажется ты понял в чём состоит неинтуитивность, которую мы с Ромой предлагаем устранить, может быть у тебя есть какие-то другие мысли как это сделать?

[alx]

Replying to san:

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

Во-первых, не выдумывай. :) Пользователь, конечно же, может удалить данные, которые он ранее ввел в параметр "SIP URI", ровно так же, как он эти данные установил - введя вместо них новое значение и затем записав конфигурацию в плату. Да, здесь есть некоторые ограничения - например нельзя ввести пустую строку (веб-интерфейс валидирует ввод, проверяя, чтобы в URI был символ '@'). Но удалить 11@192.168.20.120, введя вместо него например a@b, ничто не мешает.

Во-вторых, и это главное, roman_zhur в описанной ситуации этого НЕ ДЕЛАЛ - он не пытался менять настройки канального окончания! Он пытался его УДАЛИТЬ! Немного поясню, что произошло "под капотом" в процессе описанных событий. Когда roman_zhur перезапустил swd, swd пошел искать в конфиге настройки каждого из 256 возможных канальных окончаний. Если в конфиг-файле таких настроек не оказывается (а их там нет, так как конфиг был предварительно очищен), вместо конфигурации swd передает команду на удаление канального окончания (на случай если оно есть в плате из "прошлой жизни"). Именно таким образом из платы пропали канальные окончания АДАСЭ и FXS. Но, как я уже писал выше, канальные окончания 255 и 256 удалить нельзя, поэтому они просто проигнорировали команду удаления и "пережили" рестарт swd.

Чтобы было еще понятнее, попробую показать на примерах на низком уровне. Конфигурация канального окончания, найденная в конфиг-файле, представляет собой JSON-объект, например такой: {"type":"FXS","uri":"fxs2@server.com"}. Если эту строку записать в переменную .10.2.1.0 платы VE-02, в ней будет создано канальное окончание канала 2. Если затем записать туда же {"type":"FXS","uri":"labuda@dabuda"}, канальное окончание изменит свой URI на "labuda@dabuda". Можно даже записать туда пустую строку, как предлагал roman_zhur - {"type":"FXS","uri":""}! Через веб-интерфейс этого сделать не получится, он сругается, но можно вручную вызвать команду API например из адресной строки браузера примерно так:

​http://<адрес платы>/api.php?json={"cmd":"snmpset","varlist":{".4.5.10.2.1.0":"{\"type\":\"FXS\",\"uri\":\"\"}"}}

И URI станет пустой строкой (правда работать канальное окончание перестанет)...

А теперь, внимание: если записать в ту же переменную пустую конфигурацию ({}) - канальное окончание будет удалено из платы. Можешь попробовать сделать все это на практике...

Но если ты попытаешься записывать то же самое в переменную .10.255.1.0, ты увидишь отличия в поведении. А именно:

• вместо канадльного окончания "FXS" будет создаваться канальное окончание "FS01" независимо от того, что ты укажешь в параметре "type";
• запись строки {} не будет иметь никакого эффекта.

Так вот, возвращаясь к тому, откуда я начал этот длинный экскурс: roman_zhur не пытался записать {"type":"FS01","uri":""} (или любое другое значение параметра "uri"). Он записывал именно пустой конфиг ({}), то есть пытался удалить канальное окончание.

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

Потому что канальные окончания 255 и 256 нельзя удалить, но он этого не знал, так как это не написано в РЭ. Имеет место банальное упущение в документации...

Алексей, кажется ты понял в чём состоит неинтуитивность, которую мы с Ромой предлагаем устранить,

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

Во-вторых, я здесь видел только предложение roman_zhur (оно в описании тикета).Мое решение по предложению roman_zhur написано выше. Никаких новых аргументов в пользу этого предложения вроде бы не было. От тебя предложений я не видел. Если они у тебя есть, изложи их, пожалуйста - либо создав новый тикет, либо хотя бы в комментарии к этому...

может быть у тебя есть какие-то другие мысли как это сделать?

У меня нет мыслей о том, как устанавливать пустое значение параметру "uri", так как саму идею как таковую устанавливать параметру заведомо невалидное значение я считаю плохой.

[alx]

Replying to alx:

От тебя предложений я не видел.

О, я только сейчас сообразил, что твое "Предложение в том, что..." в comment:4 - это и есть твое новое предложение. Это так? Я сначала думал, что это ты пишешь о предложении roman_zhur, написанном в описании тикета...