On 11.02.2008 20:13 CE(S)T, Peter Brawley wrote:
If user.additionalkeylist and tag.readaccesskeylist are not lists,
naming them `...list` misleads & distracts.
Well, these fields contain KeylistId values from the "keylist" table, so
I thought naming them *Keylist would be good enough.
But on (i), how user.additionalkeylist and tag.readaccesskeylist work
remains confusing. You appear to say access may come from ...
(i) message->message_revision->message_revision_tag.readaccesskeylist, or
(ii) message_revision->user.additionalkeylist
which implies there are positive values which provide access, but your
original query used the condition
readaccesskeylist /is not null/
as a test for access /refusal/, which seems to contradict what you now say.
message.ReadAccessKeylist and message.SearchRevision->
message_revision_tag.ReadAccessKeylist are a list of keys of which *one*
is required to get in.
user.AdditionalKeylist is a list of keys that the user possesses and of
which *one* can be used to get in.
One list contains the keys that can be used, the other two lists contain
keys that are allowed. One gives keys, the other accept keys. Imagine it
like the user coming along with a keyring, trying to open a door with
multiple keyholes. One of his keys must fit in one of the keyholes to
get in.
And the problem here is that I need to test whether there is not a
single tag for a (known) revision of a message that has an associated
keylist to which no keys of the session user fits. If there was such a
tag, access would be denied. To grant access, there must only be tags
that either have ReadAccessKeylist IS NULL or that contain a key to
which one of the session user's additional keys fits.
I'm still wondering if there's a way to explain all this better with
some graphics.
--
Yves Goergen "LonelyPixel" <[EMAIL PROTECTED]>
Visit my web laboratory at http://beta.unclassified.de
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
