here's a few other idea, which are probably more complicated:

1) make 2 tables at the user schema level. you have the 'real' table, which is what is exposed now. make this table non-editable to anyone.

then either:

2a) make a regular query that has a WHERE clause that appends a filter by userid. see ismemberof() in LK SQL for one option. this way it can get removed (unlike user filters). to this query, add custom buttons. these buttons could test permissions, and enforce row-level security. this would have problems exposing row-level update UI though.

2b) expose a table that only will ever show rows belonging to the current user. to do this, at the user schema level, expose the original table twice. expose the regular table (ie. as in option #1). then also expose a clone of this table that is filtered on UserId. This new table will only show only those rows belonging to the currently logged in User. LookupSetTable or LabworkType table in EHR module (see also EHRUserSchema) are roughly what you'd want. this new table would behave exactly like a regular LK table; however, it would only give the user the opportunity to edit their rows. unfortunately, it also only shows them their rows.

The above gives you one table for reading and one for editing. If you need to have a single table showing all records, but conditionally showing the EDIT link, then my only idea is:

to your original table, hide the normal edit UI (which always appears), and then add a custom java column that only shows the 'EDIT' link for rows belonging to the current users. to hide edit UI, make <updateURL></updateURL> empty. to your table, add a new AliasedColumn and make a java DisplayColumn for this new column. If you're interested in this route i'll write more. This would handle the UI part if rendering a DataRegion; however, you'd want to actually enforce edit permissions on the server. That's important b/c otherwise anyone could still edit rows through any other client API path. Ideas are:

a) create a JS trigger script and test/enforce permissions there. this would be simplest, i think. check out employeecategory.js as a simple example of what these trigger scripts are. in your example, you'd make a beforeUpdate(), and within this you'd test whether the current UserId matches the field in the oldRow (ie. original row) that corresponds to that User. if not, throw an error.

b) write your own java UpdateService. you could do something similar to above.

I've done things like both of these in different places.