I have just been trying a different approach to separate my user table (user_id, u_username, u_password, u_userlevel, u_activated etc) from my client table (client_id, cli_name, cli_phone, cli_turnover etc) and started testing detail additions on a master/detail page. As you probably all know, I now realise that it is the field on the 'many' side of the master/detail join that has the 'one' side (Primary Key) inserted as the foreign key in the new detail record (just as in the MS Access parent/child join fields) BUT if record level security is also configured, and the detail table contains a target user_id field, then of course this also gets populated (derived from the user_id of the logged-in user). In other words, the user_id in the new detail record has nothing to do with its master table.
I was a bit confused because the help file demonstrates the simplest case of Employees and Orders - separating out the user table is not obvious. In a real-world application, many of the 'people' tables will be designed to store very different types of object (teachers, students, cleaners, contractors etc) and having a single multipurpose table would be very cumbersome. The basic constraint in PHPMaker is due to the fact that you can only refer to ONE User ID from ONE specific table for Record Level security. Having a separate USER table for user ids and other login details should enable a more flexible design.
NOTE: When you create a new User (eg a teacher) you simply have to ensure that her new user_id (PK) is also inserted as a Foreign Key into her personal record (teacher_id (A/I PK), tea_user_id (FK), tea_name, tea_qualifications etc) in the 'teacher' table - this would stop her seeing the other teacher records.
Of course there may be another approach to this issue but I will report back if I hit a brick wall. I look forward to any comments and hope it helps someone out of the fog.