have you tried checking the "run script with full access privileges" to make sure it's not an permissions issue?
If the only difference is the admin vs. user privilege set, that indicates something's up there.
Yes I have ran it while checking the "run script with full access privilages" and have checked our security privilages for users which are set to yes and all for records with no change in results... The users are able to delete records, only the first record will not delete.
You may be trying to delete the one record that is both the Parent and the top Portal record.
Check your relationship graph to see which table is the parent of the portal and see if Parent and Child come from the same table.
If so, you will need to find another table to use as the parent.
Best wishes - Alan Stirling, London UK
The portal is from a different table than the layout table, the layout has the primary key for the poryals foriegn key. I am able to delete the first record as an Admin, but not as a User, the other records delete just fine for both user and admin...
Thanks for the thought!
Mike wrote, in part:
Mike is onto something regarding permissions.
Is there any subscript called by the full access script that also needs to be run in full access?
Can you post the script steps....
Is there any sort of validation or conditional/limited record editing at the users' permissions level?
yes, posting some screenshots of the layout, scripts, privilege sets and relation would all help a little.
Of course if privacy is a concern, you could avoid some frustration by hiring a consultant to take a look at your file.
I've had a similar issue where even selecting the "Run script with full access privileges" option does not allow me to delete a portal row when logged in with lesser privileges. The solution was to do the following:
Instead of selecting "No" to disable ability to delete a record from that table in the security settings, change the option to "Limited" with the calculation:
Get(CurrentPrivilegeSetName) = "[Full Access]"
Then make sure that you script the portal row deletion to "Run with full access privileges". Your script could also check the users login privileges via: Get(AccountPrivilegeSetName)
The actual "Delete portal row" script step could be placed in order so that other criteria must also first be met... such as to only allow deletion of the portal row if the record was originally created by that user or within a certain timeframe from the creation timestamp.
This worked well in my case anyway.
hmmmmm... this allows the delete, but I'm noticing now that ANYONE with that level of security can delete now even with a basic one-line "Delete Portal Row" step with or without the "Full access" option. It seems like I either can or can't delete a record based ONLY on "Yes" or "No" in the "Delete" option in security settings.
I dealt with the above issue by allowing record deletion based on a value in a global field that is set at the start and end of a script and preventing the user with lower access privileges from seeing that field or changing its value from anywhere else. These apparent privilege set problems may be relevant to the original question in this thread, but you would think it might affect deletion of any record from a given table, rather than just the first record in the portal ??
I believe this bug still exists in the latest v12. Clients can wait awhile, move around to other records then return, or ask another to delete the row when this happens. You could got to related and delete, but more code and not very elegant.
To be clear, this can happen even if you have full access. It appears often on the first row (it seems) but I have seen it happen most often on the last entered row.
When this happens, I can usually switch to another parent record, add a portal row, and delete it -- so the problem is not with access or scripting. Return to the original problem parent record, and the child still cannot be deleted. Sometimes, if you wait long enough, the record can then be deleted.
When this happens, a button with "Delete portal row" does not work. Also, you cannot delete the portal row in question by selecting the row and pressing "delete," or when using the standard "Delete record..." menu option, and then choosing "Related." which of course gives you the same non result.
All of the above is happening to me right now with full access. As noted by others, using GTRR and deleting the record (or all related portal rows) does work.
I will confirm that this is a long standing bug in FileMaker that I have seen many times. Delete Portal Row does not always work...in several situations where it should.
I've not come across this problem, do you have any more info? Does it occur within all OS's?
I've witnessed this on both Mac server and Windows server, Mac client and Windows client.
The permissions settings can also be configured for which scripts users have access to based on their permissions. You can disable/enable this specific script for the appropriate permission groups even though it is running in Full Access mode, so the appropriate users can call it and others cannot.