Restriction Table notes
-----------------------

Initially there will be two tables added:

   s_restriction_type
   ------------------
     type  VARCHAR(10)
     description VARCHAR(60)

   restriction
   -----------
     owner_id  -> %user.id
     user_id   -> %user.id
     s_attribute_type -> %s_attribute_type.s_attribute_type
     value VARCHAR(255)
     s_restriction_type -> %s_restriction_type.type

Anyway the idea is that there would be various restriction types that could be entered into this table.

For example:
    s_restriction_type := 'NOTVIEW'

Would be used to configure users who cannot view listings of a particular users items:

For example the functions/item.php would have an extra where clause added:

   AND owner_id NOT IN (...)

The (...) would be found by querying the restriction
table as follows:

   select owner_id
   from restriction
   where s_restriction_type = 'NOTVIEW'
   and user_id = '$user_id'

A new functions/restriction.php script would be added to provide interfaces into this table, 
to allow queries,edits,etc.  For instance a function that returns a comma delimited list of
user_id's for use in the NOT IN clause would be useful, as well as simple boolean functions
such as:

   is_user_allowed_to_borrow($owner_id, $borrower_id)

Or for item_instance level restrictions, the following function might be required:
   is_user_allowed_to_borrow($item_id, $instance_no, $borrower_id)

The crux behind this whole structure is the meaning connected to the s_restriction_type.type's
and the that the functions in function/ restriction.php are aware of the particular types...

The 'value' column in the restriction table is provided for the situation where a particular
restriction may require a configurable value.  For example, a user may want to restrict the
number of items a particular user is allowed to borrow/reserve.

Restrictions could be global by not specifying a owner_id; Obviously only Administrators could
insert global restrictions.  All this stuff will be able to be edited via a script, with access
restrictions for various levels of users.

Because I really like this idea and I can see where it can be applied to other areas of the
system, I am actually going to start looking at it now.  So it may well be in a release
much sooner than 0.70!!!


Addendum:
's_attribute_type' -> %s_attribute_type.s_attribute_type so that restrictions can be applied
against particular item_attributes.


EXTRA NOTES
-----------

I have decided to remove any reference to individual item_id/instance_no as this is
taking the functionality too far, and would severly affect performance.

The basic functionality of a restriction table would be to configure a users restrictions only.
But this could include:

Which owners a user can/cannot view/borrow items from.

How many items a user can borrow.

How many items of a certain type a user can borrow.

Whether a user can even see particular types.

A user cannot view items where a item_attribute = a
certain value, or combination of values.  This one
would be useful to restrict access to X or R rated
films.   

These restrictions would be dealt with by modifying
the SELECT statements used to build lists, or the
is_user_????? validation functions.

NOTE:

The restriction to start with first would be a:
   is_user_allowed_to_borrow($item_id, $borrower_id)

This function would check the restrictions table for
any entries of the form:

   owner_id = 
   user_id = $user_id
   s_restriction_type = 'NOTBORROW'

This sort of restriction will be more straightforward
than restrictions on whether a user can even see a listing of
particular items.

We could also add a restriction for 'NOTVIEW', but this
could not be implemented in listings.php or search.php
straight away.

If you are happy to work with NOTBORROW and NOTVIEW
to start with, I can fast track the funcionality and
have something for you very quickly.

The 'NOTLIST' for listings.php and search.php (If you
cannot list owner items, then the owner should not
be in the list of values in search page!)


MAX BORROWING RESTRICTIONS:

How the restriction table would work in this instance:

   owner_id = NULL; # Site wide
   user_id = $user_id;
   s_item_type = NULL; # All types
   s_attribute_type = NULL; # Not needed.
   value = '5';
   s_restriction_type = 'MAX_BORROW';

So your $user_id could not borrow more than
5 items at once, and the restriction would kick
in when the user tries to reserve an item.  The
[Borrow] / [Reserve] links would still be displayed
in listings.php/item_display.php as the logic to
test in these would complicate the generation of
these pages too much.  A message would be displayed
in borrow.php when a user tries to reserve an item
that would breach their limit.

Also a particular owner could also limit the number
of items a user actually borrows from them:

   owner_id = you;
   user_id = $user_id;
   ...
   value = '5';
   s_restriction_type = 'MAX_BORROW';

You could also restrict the number of items of
a particular type a user borrows:

   owner_id = NULL;
   user_id = $user_id;
   s_item_type = 'CD';
   value = '5';
   s_restriction_type = 'MAX_BORROW';

So $user_id could not borrow more than 5 CD's
at once.

The global restrictions would be checked first,
followed by the more particular:

  Check max items
  Check max items at s_item_type level
  Check max items for owner
  Check max items for owner at s_item_type level

And so on...
