Этот загадочный Total

[Idea]

Доброго времени суток!
Возникла у меня неприятная проблемка. Пишу базу данных заявок на поставку товаров\услуг и тп. Есть в ней вьюшка "Все заявки\По авторам", в которой отображаем соответственно все заявки, отсортированные по авторам. В последнем столбце отображается стоимость заявки и суммы по категориям. Заявки отправляются на согласование проректорам (проректоров несколько), и вот такая беда - заявки, прошедшие через других проректоров, отдельно взятый проректор не видит (прописано в Readers-ах), но в итоговую сумму они включаются. Как можно этого избежать? Спасут ли личные представления (не очень хотелось бы использовать, принимая во внимание то, что постоянно приходится что-то править в уже внедренной базе)?
Есть ещё момент - сейчас я использую это представление не только для проректоров, но и для других вышестоящих отделов, но их права на чтение определяется не по имени пользователя конкретного, а по роли. Некоторые другие отображения я делала через форму и категоризованные встроенные представления (альтернатива Private видам), но в них было можно отсортировать по какому-то одному значению. А с этим видом так не получается, ибо один и тот же документ должен отображаться у пользователей с разными ролями, соответственно универсальную категорию я никак не могу придумать.

 

[Constantin A Chervonenko]

Давай "по логике":
Total-ы, как и номер - свойства вьюхи как серверного объекта. Что в неё попало - пронумеровано и просуммировано :-(
Приватная вьюха МОЖЕТ иметь в фильтре @UserName и, т.о., исключит "лишние" строчки из суммы.

О! А Single-Category тебя не спасет? Собери все READERS в 1-ю колонку

PS: домашнее задание. Придумайте полезное применение этому "глюку" Totals

 

[Idea]

О! А Single-Category тебя не спасет? Собери все READERS в 1-ю колонку

Да я бы с радостью собрала, только что-то не собирается. Ридерсы у меня построены, возможно, не рационально, но зато работают как надо. Полей типа Readers у меня аж 6 штук, пришлось это сделать, так как, когда я записывала всех в одно поле (кодом лотусскрипта), лотус путался с разделителями и после долгих мучений сделала всех отдельно. То есть, когда пользователь или группа могут читать документ, они прописаны в соответствующем поле, а когда нет, оно пустое (""). Так вот я не могу придумать формулу, по которой мне собрать категории в первую колонку Словами это примерно следующее: если поле ProReader не пустое, то выводим его значение, если PlanReader не пустое, то выводим "[Planner]" (роль) и тд, и вроде как никаких проблем, только вот может быть, что и первое не пустое, и второе, и тогда документ должен отображаться и в первой и во второй категории, а реально получается, что вот по этой формуле колонки:

 @If(
ProReader !=""; CurrProrectorName;
PlanReader ="[Planner]"; "Planner";
AccReader = "[Accountant]"; "Accountant";
JurReader = "[Jurist]"; "Jurist";
RecReader = "[Rector]"; "Rector";
"Leader")

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

 

[Constantin A Chervonenko]

Лотус с разделителями не путается, в мульти-полях никаких разделителей нет, это только в UI (на экране) они имеют значение (при записи в базу строка по ним бъется в массив).
Так что вы сами запутались (да и меня запутали).

МыслЯ была в 1-колонке написать что-то вроде @Unique(@Trim(Readers1:Readers2: .. ReadersN))
а потом для SingleCategory выбирать по @UserName. Ну, или по @UserRoles - если роль (значимая) у юзера одна. Вот если их много ... хреново .. не соображу

 

[Idea]

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

 

[Constantin A Chervonenko]

В принципе проблему я бы определила так: конкретный документ хочет отобразиться на вью только один раз

Фигня. Конкретный док-т отображается во вьюхе столько раз, во сколько категорий он входит. Это азы ...