Passing information from views to base tables in Oracle (SQL) - sql

Question

I have a slight problem!
I have an original base table "StaffAddressDetails":
CREATE TABLE StaffAddressDetails
(ContactID INTEGER NOT NULL,
Postcode VARCHAR (10) NOT NULL,
HouseNameOrNumber VARCHAR (50) NOT NULL,
Street VARCHAR (50) NOT NULL,
Street2 VARCHAR (50) DEFAULT '...',
Town VARCHAR (50) NOT NULL,
County VARCHAR (50) NOT NULL,
Country VARCHAR (50) NOT NULL,
StaffID INTEGER NOT NULL,
CONSTRAINT StaffAddressDetails_PK PRIMARY KEY (ContactID, Postcode),
CONSTRAINT StaADContactIDSCD FOREIGN KEY (ContactID)
REFERENCES StaffContactDetails (ContactID));
I want the members of staff to be able to see only their own details, so I have a created a view "HDPBHTTSKStaffAddDetsForSelf" and granted that view to a role "Teacher":
CREATE VIEW HDPBHTTSKStaffAddDetsForSelf AS
SELECT * FROM StaffAddressDetails
WHERE StaffID IN
(SELECT USER
FROM DUAL);
...and...
GRANT SELECT, INSERT, UPDATE ON HDPBHTTSKStaffAddDetsForSelf TO Teacher;
That all works fine - the problem comes when inserting a new row (when logged in on a teacher's account) should, say, the teacher acquire a new address and wish to add it to the school system.
The inserted row appears when queried from that teacher's account, but does not pass down to the original base table, meaning no-one except the teacher can see it, not even admin.
Is there a quick fix??
Many thanks in advance,
Zulu

Answer 1

You should use the WITH CHECK OPTION when creating your view, so that Teacher role members cannot insert or update data with different StaffID than their own, i.e.
create view ... as select ... from ... where ... WITH CHECK OPTION;
Further, agreeing with #danihp, only reason I see why data seem not being passed down to the table for the admin to see, is that inserting transaction is not being committed.

Answer 2

According to my "Pro Oracle Database 11g Administration" book:
If you don't want a user to be able to perform INSERT, UPDATE, or
DELETE operations on a view, then don't grant those object privileges
on the underlying table(s) to that user.
Of course, you want to allow DML operations to the underlying table. To me, that says you also need to make sure that the "Teacher" has appropriate permissions on the StaffAddressDetails table, as well.
GRANT SELECT, INSERT, UPDATE ON StaffAddressDetails TO Teacher;
And to echo Carl's answer, it's a good idea to create this type of view using WITH CHECK OPTION.