[racktables-users] Re: Very minor bug

  • From: Denis Ovsienko <pilot@xxxxxxxxxx>
  • To: racktables-users@xxxxxxxxxxxxx
  • Date: Thu, 13 Aug 2009 23:15:45 +0400

[...]

> 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.

Other related posts: