[...] > Also, the rackcode is entered in Configuation --> Permissions. It isn't > just used for permission though so perhaps it should be renamed Rackcode > or something? It's not a big deal but when I was first trying to find > where to add the Rackcode (even though I'd seen it before) I was hunting > all over the place for it. There is a story behind the fact, that one has to open "Permissions" to add a filtering item for list viewer. These predicates are actually boolean functions, which you can use in allow/deny clauses, they were added to make access policies shorter. This is why you are warned about "unused" predicates: it was initially assumed, that their primary purpose was to be used in the text, which describes access policy. The initial spec of RackCode language allowed redefining an existing predicate right in the access policy. This way the actual meaning of a boolean function could change as long as no prevoius allow/deny clauses were selected. This is why "define" clauses reside in the same text with "allow" and "deny". Eventually it became clear, that such redefinitions don't add much functionality, but cause problems in the language processor, so I changed the spec. In theory, storing predicates in some "library" outside the actual access policy would not change anything. In practice, it already works reliably. At the time I implemented tag filter as it is seen on 0.17 series I realized, that custom filters need to be stored somewhere. One of the key innovations about the filter (for me) was ability to filter list by any RackCode expression (you can enable it in User interface config). This made possible to see, which particular items do you mean, when you write "allow" or "deny" with many conditions. And predicates seemed most reasonable bridge between tag filter and RackCode at that time. That's why custom filters are configured in "Permissions". This may change later to a better design, of course.