own record editable, rest read-only

[sysadmin]

Hi, I've inherited an FMP db with a timesheeting component. Everyone can see and edit their own timesheets. Previously only users of a certain privilege set could see all of the timesheets. The boss wants everybody to be able to see each others' timesheets now, but read-only.

The mechanism to 'prevent' access by a normal user was to set 'no access' to the value list of account names. So I've set it to 'read only' and now everyone can see everyone else timesheets. The problem is, each user can add and delete (through a portal on the layout) each others' timesheet entries (in a related table).

I've looked through the privileges that are available and it appears I can only set privileges at the table or field level. Is there a way I can allow access to a user's own record and related timesheet entries, while only providing read-only access to the other records and timesheet entries?

Thank you!

[Steven H. Blackwell]

First, welcome to FM Forums.

Is there a way I can allow access to a user's own record and related timesheet entries, while only providing read-only access to the other records and timesheet entries?

Yes, this is easy to do. it's called Record Level Access or RLA. Basically you have a field that identifies the record creator. When the current account matches that, user can edit the record. When there is no match, other users can see but not edit. The business with the value list is a distractor. it offers no protection at all, nor did it do so in the past.

Search for RLA here in FMF and see recommendations people have made. if you need more help, come back.

Steven

[sysadmin]

Hey, thanks for the prod.

I've found what I was after - I was in there in the first place, of course, I'd just chosen the 'field access' dropdown and not found anything helpful. It was the 'limited...' option that I wanted.

If ( Get ( AccountName ) = Staff::Account Name; 1; 0)

^^works a charm

That's great, it's almost complete. However, under 'create' it just has yes or no - so my users can't edit or delete the records of others, but they can still create. : I can't set this to 'no', because they still need to be able to create their own timesheet records.

It seems weird that FM would have 3 of the 4 standard CRUD able to be 'limited' - is there some setting or feature about the table or relationship that is preventing me from limiting on creation? I Google'd and browsed the docs, but nothing is coming up helpful.

Oh, by the way yes, I figured the value list limiter wasn't secure at all - that's why I put it in inverted commas. :

Edited August 5, 2009 by Guest

[sysadmin]

I've just done a more comprehensive Googling and it appears that the 'limited' option omission on 'create' is intentional. I can't find any explanation for why though.

Is there a reasonably easy-to-implement workaround?

[bcooney]

I don't understand why Create should be limited. When they create the record, their AccountName is stored in a CreatedBy field, right? Then your RLA calc should be allow edit if Get (AccountName) = CreatedBy.

[sysadmin]

When they create the record, their AccountName is stored in a CreatedBy field, right?

There is no 'CreatedBy' field. I can create one and store the account name there, but how that will that stop my users from creating timesheet records for other users?

My understanding is, for it to work the implicit steps would have to be:

• Create invokes the creation of a container that has only the property of being created by "AccountName"
  
• Data is entered by user of AccountName
  
• Record commit is actually an Edit action which can now be 'limited' by AccountName - otherwise it is discarded.

Further explanation:

Staff has many Timesheets (relationship)

• All Staff should be able to View all Timesheets records.
  
  
• All Staff should not be able to Update or Delete records in the Timesheets table which are not currently theirs.
  
  
• All Staff should not be able to Create records in the Timesheets table which do not become theirs.

[bcooney]

Nothing will stop them from creating records for other users, except a clear interface. It should be obvious that they are creating records to input their data.

You need a field in the table CreatedBy that is auto-entered Account Created.

I don't know what you mean by "creation of a container".

[sysadmin]

Yeah, don't worry, it's a hard concept to explain in a forum post, and I've verified that it's not the case. Create is an action unto itself - and one that cannot be limited by the looks of it.

I'm not worried about people unintentionally creating records for other people (which would be the reason for the 'clear interface' argument) - I'm concerned with intentional creation.

I suppose the only way to simulate the 'limited...' option is disable the FMP menus and use a button that invokes a script that checks first - right?

Thanks for all your help guys!

PS I think I get what you mean - if a user creates a new timesheet record, regardless of what records they're currently browsing it should belong to them! Aha! The Filemaker Way™ reveals itself.

Unfortunately, that's not achievable with the way the system has been designed (against the Filemaker Way™, obviously). The recordset that the timesheet layout shows is dictated by a global, that also pulls in the projects to which the person belongs, which then links that back to the billing module of the project. It's far too complicated for me to go changing the behaviour of this one small part - the repercussions are unfathomable. I'm developing a RoR system to replace this anyway, so I was only after straightforward or simple changes to the legacy system.

Thanks again!

Edited August 6, 2009 by Guest