Help/suggestions with record filtering by user [message #1435] |
Wed, 09 July 2008 15:45 ![Go to next message Go to next message](/theme/default/images/down.png) |
bonzo_bcn
Messages: 152 Registered: June 2008
|
Senior Member |
|
|
I have table called 'people' that stores personal data (name, address etc.).
This table is filled by two types of users: schools and super_schools.
Each school should only be able to see the persons they have created, super_schools must see all records.
One same people record can be created by many schools: in this case the first one would do an insert and the following transactions would do nothing (or maybe update), but the second and third schools should also be able to see the 'people' record.
What do you suggest for this scenario?
|
|
|
|
|
Re: Help/suggestions with record filtering by user [message #1438 is a reply to message #1437] |
Thu, 10 July 2008 05:26 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
AJM
Messages: 2361 Registered: April 2006 Location: Surrey, UK
|
Senior Member |
|
|
If you are hoping that there is something in the Radicore framework that will achieve this automatically then you are out of luck. There are only two levels of security available:
(1) Task-level security, where a user either has permission to access a task, or he doesn't. When running a task there are no restrictions on which data can or cannot be accessed.
(2) In some cases several accounts can share the same database, but users within an account are restricted to data owned by that account. The data within the shared database is said to be partitioned by account. This can be implemented using the procedures documented in http://www.tonymarston.net/php-mysql/virtual-private-databas e.html.
Item (1) is a fundamental feature of Radicore and cannot be turned off. Item (2) is entirely optional and can be turned on when required.
What you seem to be asking for is outside the scope of either of these options, so cannot be implemented without changes in your database design and the addition of custom code.
Each 'person' record is restricted to a particular group of users, but can also be viewed by a 'super' user. This means that you must have a column on the 'person' table which identifies the class of the user who created it. Then when reading from the 'person' table you must identify the class of the user, and if he is 'restricted' you must add the following to the WHERE clause of the sql SELECT statement:
... AND class='user_class'
This can be done by adding the relevant code in the _cm_pre_getData() method.
In short, the framework cannot do what you want automatically, but it does not prevent you from inserting custom code which is tailored to your needs.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
Re: Help/suggestions with record filtering by user [message #1439 is a reply to message #1435] |
Thu, 10 July 2008 06:41 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
bonzo_bcn
Messages: 152 Registered: June 2008
|
Senior Member |
|
|
sure it doesn't do what I want out of the box, I didn't expect that ![Smile](images/smiley_icons/icon_smile.gif)
I'm trying a workaround, but I'm stuck here, maybe you can help:
When a school creates a person I use _cm_post_insertRecord to automatically insert a record in pers_school_xref with the person_id and the user_role, this way I know that the users that have that user_role can see the records.
The problem arises when a second school wants to create the same person, I'm trying to find a way in that no data is inserted in the person table, but a record is created in pers_school_xref with the person_id and the second school user_role.
I've tried to use _cm_post_insertRecord to check if the record exists, and if it does, then insert a record in pers_school_xref and launch an error message 'Person allready created' so that the person is not inserted again, but it is asigned to this school, the problem is that it rollbacks the insert in pers_school_xref.
Is there a way to save the record in pers_school_xref but not in person when a school tries to insert in person table?
|
|
|
Re: Help/suggestions with record filtering by user [message #1440 is a reply to message #1439] |
Thu, 10 July 2008 07:07 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
AJM
Messages: 2361 Registered: April 2006 Location: Surrey, UK
|
Senior Member |
|
|
If you put anything into $this->errors then the update is deemed to have failed, in which a rollback will automatically be performed. If you want to issue a message which is not an error then use $this->messages instead.
If you want to prevent the insert of a duplicate record for a person then doing it in the _cm_post_insertRecord() method is too late as that is performed AFTER the insert. You should use the _cm_validateInsert() method which is performed BEFORE the insert. If you discover that the record is a duplicate then return an empty array - this will cause the INSERT to be skipped, but the original data will still be available in the _cm_post_insertRecord() method so that you can update the pers_school_xref table.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
|
|
Re: Help/suggestions with record filtering by user [message #1446 is a reply to message #1445] |
Thu, 10 July 2008 11:06 ![Go to previous message Go to previous message](/theme/default/images/up.png) ![Go to next message Go to next message](/theme/default/images/down.png) |
AJM
Messages: 2361 Registered: April 2006 Location: Surrey, UK
|
Senior Member |
|
|
You are confusing me. If 'participante_id' is filled in when a new record is created then you are creating a NEW record and not preventing the creation of a duplicate.
If you require this to be the value from an existing record (ie: the record for which this would be a duplicate) then you must have code which reads the database to provide this value. If this code is already in the _cm_validateInsert() method and you do not want to duplicate in the cm_post_insertRecord() method then you must save it in a class variable so that it is available without being passed in one of the arguments.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|