Форум русскоязычного сообщества Ubuntu


Автор Тема: LibreOffice Calc. Защита листа с возможностью скрытия строк  (Прочитано 3855 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Azure

  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 6017
  • Windows10, i3wm on Debian9, Manjaro20.0
    • Просмотр профиля
Пример:
User 1 сегодня должен предоставить данные по показателям 3, 7 и 12.

Т.е. в первом варианте пользователь, ввиду того, что ему неудобно искать разнесенные показатели, просто вписал их и значения в соседние строки. С первого взгляда - вполне себе жизнеспособно. Можно смотреть на наименование показателя и в заполняемой таблице подставлять значение, соответствующее этому показателю. Но затем получаем второй вариант, где пользователь изменил наименование показателя на удобное ему. Но наименования показателей - достаточно специфичные и должны быть в первозданном варианте.
Опять упираемся в вопрос организации процесса, а не программирования.
Каким образом определяется что User1 должен предоставить данные именно по 3, 7 и 12?
Изначально был именно вариант с выпадающими списками. Но отказались, и вот почему:
Иногда пользователю необходимо указать от 200 значений. Выбирать 200 раз наименование показателя - для пользователя тяжело, ему гораздо проще проставить значения напротив нужных уже прописанных показателе.
Выбирать достаточно просто если учесть что начиная набор подставляются подходящие значения.
В Линукс можно сделать ВСЁ что угодно, достаточно знать КАК !

Оффлайн luu

  • Автор темы
  • Активист
  • *
  • Сообщений: 721
  • шта?
    • Просмотр профиля
Опять упираемся в вопрос организации процесса, а не программирования.
Каким образом определяется что User1 должен предоставить данные именно по 3, 7 и 12?
Для условий текущей задачи - рандомно. В реальности - это определяется условиями производственного процесса и не зависит ни от пользователя ни от администратора.

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

Оффлайн Sly_tom_cat

  • Don't worry, be happy!
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 12130
  • Xubuntu 22.04
    • Просмотр профиля
    • Github
luu, еще раз - вам нужна простейшая базенка с контролем пользователей и управлением тем кому какие параметры заполнять.

Я подобное на MSACCESS давно когда-то слабал на коленке. Прога потом лет 5 работала закрывая дырку в техпроцессе (перестали пользовать потому, что поменяли процесс и поставили другую ERP где эти вопросы были охвачены).
Индикатор для Yandex-Disk: https://forum.ubuntu.ru/index.php?topic=241992
UEFI-Boot - грузимся без загрузчика: https://help.ubuntu.ru/wiki/uefiboot

Оффлайн Azure

  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 6017
  • Windows10, i3wm on Debian9, Manjaro20.0
    • Просмотр профиля
В реальности - это определяется условиями производственного процесса и не зависит ни от пользователя ни от администратора.
Вы не поняли вопрос, а в нем как раз и весь ответ. Поскольку внесение данных распределенное, то User должен каким-то образом получить задание: набор параметров какие он должен заполнить, т.е. мини-таблицу только с нужными полями например.
Это проблемы текущих пользователей. … Пользователи голосуют за то, чтобы просто вводить значения напротив показателей.
Пользователи ВСЕГДА проголосуют против того, чтобы делать что-то отличное от того, к чему они привыкли. Только после административного воздействия, переучивания и некоторого времени работы могут согласится с тем что стало лучше. UI никогда не конструируется по итогам голосования. Наглядный пример: Даже Вы не опробовав предложенный метод уже выступаете против, между тем начиная ввод символов в поле вы сокращаете список до 5-10 значений. Так работают практически все базы где нужен выбор поля.
Второй способ — увязка по ключевым значениям. Из кодов полей для заполнения формируется список полей(таблица для заполнения).
Но опять мы возвращаемя к первому вопросу — как выдается задание.
В Линукс можно сделать ВСЁ что угодно, достаточно знать КАК !

Оффлайн luu

  • Автор темы
  • Активист
  • *
  • Сообщений: 721
  • шта?
    • Просмотр профиля
В реальности - это определяется условиями производственного процесса и не зависит ни от пользователя ни от администратора.
Вы не поняли вопрос, а в нем как раз и весь ответ. Поскольку внесение данных распределенное, то User должен каким-то образом получить задание: набор параметров какие он должен заполнить, т.е. мини-таблицу только с нужными полями например.
Видимо да, не понимаю вопроса. В котором есть ответ.
Внесение данных распределенное - все верно. User получает задание физически.
Т.е. на каждый показатель у _каждого_ User'а есть механический счетчик, показывающий значение определенного показателя. В заданный промежуток времени часть счетчиков показывает значение, отличное от нуля. Именно эти показания нас и интересуют.
Причем, значения показателей для разных User'ов в заданный промежуток времени - разные, но если рассматривать всех пользователей - то в сумме они могут дать информацию по всем 30 показателям.
Условно можно представить так: В разных концах города сидит несколько User'ов, перед каждым - 30 циферблатов, показывающих определенные значения. Раз в час, администратору нужно собрать данные со всех этих циферблатов и свести в одну общую таблицу. Файлы с указанными значениями пользователи присылают администратору по почте.
Т.е. задание, значения каких именно показателей указывать - пользователь получает в момент, когда циферблат показывает ему какое-то значение.

Как вариант, можно указывать значения со всех циферблатов, включая нулевые. Так сейчас и реализовано, пользователи присылают таблицу в виде (где 1 - значение, отличное от нуля, а 0 - соответственно, ноль. Фактически вместо нуля пользователи просто оставляют пустые ячейки):
010010001111100000000000000000
101000000000000011011110000000
000000110000011000000001111000
и так далее от каждого пользователя...

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


Пользователи ВСЕГДА проголосуют против того, чтобы делать что-то отличное от того, к чему они привыкли. Только после административного воздействия, переучивания и некоторого времени работы могут согласится с тем что стало лучше. UI никогда не конструируется по итогам голосования. Наглядный пример: Даже Вы не опробовав предложенный метод уже выступаете против, между тем начиная ввод символов в поле вы сокращаете список до 5-10 значений. Так работают практически все базы где нужен выбор поля.
Второй способ — увязка по ключевым значениям. Из кодов полей для заполнения формируется список полей(таблица для заполнения).
Но опять мы возвращаемя к первому вопросу — как выдается задание.
Я уже говорил - такой способ изначально и был. Не проперло. На выходе получили много ошибочных данных, несоответствие значений показателям (т.е. когда пользователь по ошибке указывал значение Показателя 1, а на самом деле это было значение Показателя 2) или наоборот недополучали данные, потому что пользователь забыл выбрать какой-то показатель и, соответственно, не указал его значение. Помимо этого много времени уходило на заполнение таблицы (поэтому и постарались исключить вождение мышью, оставив пользователю только клавиатуру).

Оффлайн Azure

  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 6017
  • Windows10, i3wm on Debian9, Manjaro20.0
    • Просмотр профиля
Как добиваются того, что показатели от разных пользователей разные? Или они могут быть одинаковые? Как тогда поступают с значениями одного показателя, полученными от разных пользователей?
Или Вы сами не понимаете о чем говорите? Каким образом Вы собирались при таком порядке выбирать ячейки для защиты/открытия?
Каким образом достигается сейчас отсутствие ошибок/какое влияние на отсутствие/ошибочный ввод может оказать способ заполнения таблицы?
Насколько сложно перейти к кодированию? Т.е. вместо «Название параметра 22» просто «22»? Т.е. если это счётчик/циферблат — можно ли на него «повесить» номер и в дальнейшем использовать не имена параметров, а просто номера/коды?
« Последнее редактирование: 27 Июля 2016, 14:51:07 от Azure »
В Линукс можно сделать ВСЁ что угодно, достаточно знать КАК !

Оффлайн tagezi

  • Активист
  • *
  • Сообщений: 359
    • Просмотр профиля
    • Информатика в экономике и управлении
Внесение данных распределенное - все верно. User получает задание физически.
Т.е. на каждый показатель у _каждого_ User'а есть механический счетчик, показывающий значение определенного показателя. В заданный промежуток времени часть счетчиков показывает значение, отличное от нуля. Именно эти показания нас и интересуют.
Причем, значения показателей для разных User'ов в заданный промежуток времени - разные, но если рассматривать всех пользователей - то в сумме они могут дать информацию по всем 30 показателям.
Условно можно представить так: В разных концах города сидит несколько User'ов, перед каждым - 30 циферблатов, показывающих определенные значения. Раз в час, администратору нужно собрать данные со всех этих циферблатов и свести в одну общую таблицу. Файлы с указанными значениями пользователи присылают администратору по почте.
Т.е. задание, значения каких именно показателей указывать - пользователь получает в момент, когда циферблат показывает ему какое-то значение.

Как вариант, можно указывать значения со всех циферблатов, включая нулевые. Так сейчас и реализовано, пользователи присылают таблицу в виде (где 1 - значение, отличное от нуля, а 0 - соответственно, ноль. Фактически вместо нуля пользователи просто оставляют пустые ячейки):
Я бы на вашем месте исключил бы вообще пользователя из цепи, так как проверка качества заполнения значений показателей в вашем случае фактически не возможна. И я даже представить не могу, как вы проверили достоверность, если у вас отчет приходит только от пользователя. Для того чтобы сделать такую проверку, нужно иметь дублирующую систему.
Кроме того, я не понимаю чем защита ячеек может помочь вашим пользователям, так как если пользователю всё равно в какие кнопки тыкать, то вы либо ему должны давать одну (вообще только одну) ячейку в которую можно ввести показатель, хотя и в этом случае он скорее всего сможет ввести не туда.
Вообще, по этому поводу написана не одна научная статья и книга: "Поведение пользователя в ситуации безразличия". Единственный способ мотивировать качество работы или исключать пользователя из цепи.
ASUS K53E, intel i5, 8 Gb, Integrated Intel® GMA HD
wiki LibreOffice
справка LibreOffice

Оффлайн Sly_tom_cat

  • Don't worry, be happy!
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 12130
  • Xubuntu 22.04
    • Просмотр профиля
    • Github
luu, у вас кривой процесс, который вы пытаетесь автоматизировать - получится криво автоматизированный кривой процесс.

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

То что у вас:
Как вариант, можно указывать значения со всех циферблатов, включая нулевые. Так сейчас и реализовано, пользователи присылают таблицу в виде (где 1 - значение, отличное от нуля, а 0 - соответственно, ноль. Фактически вместо нуля пользователи просто оставляют пустые ячейки):
010010001111100000000000000000
101000000000000011011110000000
000000110000011000000001111000
и так далее от каждого пользователя...

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

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

Уже одно то, что у вас счетчики никак не поименованы (определяются позицией) - это уже большое поле для ошибок.

Но даже и так, если пользователь будет заполнять поля: "счетчик что был 5-м в списке", "счетчик что был 15-м в списке" и т.п. то это позволит сохранить преемственность, но поменяет суть: каждый будет заполнять только свои счетчики.

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

Теперь как бы я сделал:
1. Подготавливаем N файлов с показателями относящимися к каждому N-му человеку (без пересечений по показателям).
2. раздаем эти файлы ответственным и требуем раз в месяц прислать/выложить в нужную папку заполенный файл.
3. подготавливаем общий файл с ссылками на файлы (N штук), которые лежат в соседней директории(туда из почты складывать или сами пользователи туда сливают свои файлы). Этот файл рефрешим после того когда все прислали/выложили свои файлы.
PROFIT

« Последнее редактирование: 27 Июля 2016, 18:48:10 от Sly_tom_cat »
Индикатор для Yandex-Disk: https://forum.ubuntu.ru/index.php?topic=241992
UEFI-Boot - грузимся без загрузчика: https://help.ubuntu.ru/wiki/uefiboot

Оффлайн luu

  • Автор темы
  • Активист
  • *
  • Сообщений: 721
  • шта?
    • Просмотр профиля
Ой-ой, господа... Что-то мы уже не в ту степь поехали. Вместо решения конкретной задачи вы пытаетесь поменять ее исходные данные.


Как добиваются того, что показатели от разных пользователей разные? Или они могут быть одинаковые? Как тогда поступают с значениями одного показателя, полученными от разных пользователей?
Это особенность производственного процесса. Этого специально не добиваются. Одинаковыми быть не могут, т.е. единомоментно двум разным пользователям не может быть показано ненулевое значение одного и того же показателя. Если у одного пользователя, например, "Показатель 2" имеет ненулевое значение - у всех остальных значения этого показателя равны нулю в один и тот же момент времени.

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

Каким образом достигается сейчас отсутствие ошибок?
Несколькими степенями проверок. Т.е. наш администратор формирует необходимую таблицу по всем показателям - при этом, если по какому-то показателю ввода не было (т.е. забыли или занесли в соседний показатель) - он это видит в итоговой таблице и принимает меры к исправлению ошибки. Помимо этого, такая таблица со значениями всех показателей уходит, скажем "суперадминистратору", который формирует из них большую сводную таблицу со значениями показателей в разные моменты времени и при ошибках может видеть отсутствующие значения либо значения, явно выбивающиеся из общего ряда (например, при наложении и излишнем суммировании значений).

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

Насколько сложно перейти к кодированию? Т.е. вместо «Название параметра 22» просто «22»? Т.е. если это счётчик/циферблат — можно ли на него «повесить» номер и в дальнейшем использовать не имена параметров, а просто номера/коды?
Абсолютно несложно. Более того, так и есть. На самом деле таблица имеет примерно такой вид:


Я бы на вашем месте исключил бы вообще пользователя из цепи, так как проверка качества заполнения значений показателей в вашем случае фактически не возможна. И я даже представить не могу, как вы проверили достоверность, если у вас отчет приходит только от пользователя. Для того чтобы сделать такую проверку, нужно иметь дублирующую систему.
Пользователя исключить из цепи нет возможности. Помиомо этого, представьте себе, что пользователи не в разных концах города, а в разных очень труднодоступных участках планеты, без привычной связи. Сеанс связи с "Администратором" (голосовой + отправка файла) - кратковременный, по спутниковому каналу, инициируемому человеком. Местоположение каждого пользователя, ко всему прочему, постоянно меняется в рамках его района. А сам пользователь за конкретной машиной тоже меняется, т.е. исполнителем становится другой человек.

Кроме того, я не понимаю чем защита ячеек может помочь вашим пользователям, так как если пользователю всё равно в какие кнопки тыкать, то вы либо ему должны давать одну (вообще только одну) ячейку в которую можно ввести показатель, хотя и в этом случае он скорее всего сможет ввести не туда.
Вообще, по этому поводу написана не одна научная статья и книга: "Поведение пользователя в ситуации безразличия". Единственный способ мотивировать качество работы или исключать пользователя из цепи.
Про вариант с защитой ячеек и как к нему пришли - я уже объяснял выше. А на тему пользователя - речь не идет о его безразличии. Люди, отправляющие данные, относятся к этому со всей ответственностью, но они люди. И вопрос стоит именно в том, как снизить процент ошибок, обусловленных физическими особенностями работы человеческого организма, а не безразличностью исполнителей. Не путайте мух с котлетами.

luu, у вас кривой процесс, который вы пытаетесь автоматизировать - получится криво автоматизированный кривой процесс.
Собственно мой опыт показывает, что пользователей слушать нужно только в пол уха. То что они говорят, что то, что они делают сейчас и нужно сохранить в системе - вовсе не значит, что когда вы их бардак автоматизируете, то они не захотят иного - более оптимального решения, которое смог бы предложить еще на этапе дизайна решение аналитик, который понимает не только в ИТ, но и в предметной области.
Может процесс и кривой, но задача не об этом. Снова пытаетесь вводные данные изменить, вместо решения. На тему вашего опыта, пол-уха и т.п. - говорил выше. Ваши пользователи и наши исполнители - это люди совсем разного порядка, поэтому давайте тут без этого...

Это уже криво по многим аспектам (можно ошибиться в "нулях" и съедут показания - это только самый очевидный минус).
Вы вообще тему читали? О каких нулях речь? Для понимания - можете перечитать вот этот пост.

Уже одно то, что у вас счетчики никак не поименованы (определяются позицией) - это уже большое поле для ошибок.
Но даже и так, если пользователь будет заполнять поля: "счетчик что был 5-м в списке", "счетчик что был 15-м в списке" и т.п. то это позволит сохранить преемственность, но поменяет суть: каждый будет заполнять только свои счетчики.
Шта?! Снова сюда, пожалуй.

Так вот, когда у вас будет несколько файлов с записями типа "название счетчика", "значение" то из них легко собирается общий список причем имея идеальный список - будет понятно каких значений не хватает. А дублирование (возможное в вашей схеме) убирается тем, что у каждого - свой индивидуальный список показателей.
Абсолютно верно! Абсолютно в точечку! Именно такой логики я и придерживаюсь. За одним лишь исключением: Невозможно дать каждому индивидуальный список показателей! Они могут поменяться независимо от пользователя или администратора!

Теперь как бы я сделал:
1. Подготавливаем N файлов с показателями относящимися к каждому N-му человеку (без пересечений по показателям).
Еще раз повторим: Нельзя жестко соотнести определенные показатели с каким-то конкретным Пользователем! Это зависит от производственного процесса и повлиять на это невозможно.

2. раздаем эти файлы ответственным и требуем раз в месяц прислать/выложить в нужную папку заполенный файл.
3. подготавливаем общий файл с ссылками на файлы (N штук), которые лежат в соседней директории(туда из почты складывать или сами пользователи туда сливают свои файлы). Этот файл рефрешим после того когда все прислали/выложили свои файлы.
PROFIT
2. В общем-то, так и сделано. За исключением временного периода - чаще, чем раз в месяц.
3. Но вопрос в автоматизации сбора данных из файлов и не стоит - с этим мы справились. Профит получен. Вопрос в снижении процента ошибок на этапе ввода данных.


Я ваши мнения услышал, принимаю к сведению. На вопросы, которые задавились - ответы получил. Всем спасибо за дельные советы - "будем попробовать что-то сделать". На этом можно закончить, я думаю.

Оффлайн Azure

  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 6017
  • Windows10, i3wm on Debian9, Manjaro20.0
    • Просмотр профиля
Речь о том что заменить «002; Показатель Б; номер_с_буквами; другой_номер_с_буквами» на «2» (вплоть до того, что на сам циферблат наклеить или краской написать.
Тогда даже exсel не нужен. Достаточно будет файла даже простого текстового формата:
Код: (xml) [Выделить]
2 value2
10 value10
11 value11
23 value23
который будет легко импортирован в таблицу.
С пользователей надо максимально убирать «сложные» процедуры перенося их на программы (или продвинутого сотрудника)
В Линукс можно сделать ВСЁ что угодно, достаточно знать КАК !

Оффлайн Sly_tom_cat

  • Don't worry, be happy!
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 12130
  • Xubuntu 22.04
    • Просмотр профиля
    • Github
luu, так я не предлагаю вам готовое решение, я говорю о подходе.
Индикатор для Yandex-Disk: https://forum.ubuntu.ru/index.php?topic=241992
UEFI-Boot - грузимся без загрузчика: https://help.ubuntu.ru/wiki/uefiboot

 

Страница сгенерирована за 0.056 секунд. Запросов: 25.