... the impossibility of deactivating this condition... is ridiculous.
You could have a one-line script: Exit Script [ false ] and assign it to the portal's onObjectKeystroke script trigger.
Thank you, Peter...
I refused to think about implementing this patch, clearly M/D launched it without being finished (since when "delete a row of portal" became a mandatory condition for inserting a portal ? ).
Something there is not finished and it was necessary to block it.
I never allow Deletes by users by configuring their accounts with FileMaker Security to not allow them (always use FM security to control permissions and don't rely on the user interface for security). Anything they need deleted has to be via script and I have a Delete script that takes JSON of the record and all fields and stores it in a Deletes table before deleting so everything has roll backs, and proof of who deleted it.
There is a reason for this:
If "Allow deletion of portal records" is checked, when user has active portal row and click "Delete record" (or use script step "Delete Record") it will delete record in portal, not the parent record. Active master-detail-portal record is always same as the parent record, so this feature makes clear sense.
This checkbox does not have effect on "Delete portal row"-script step.
I also wondered that the portal can't be sorted or filtered, at first seeing it.
But for deleting, when you delete portal row you delete current record since if you select portal row it change current record immediately. So you don't need to prevent it in portal.
I suppose the usability of unchecking would have been to avoid the action of Backspace key when a row is activated; that is probably the goal of PeterDoern workaround.
user19752 a écrit:[…]But for deleting, when you delete portal row you delete current record since if you select portal row it change current record immediately. So you don't need to prevent it in portal.
user19752 a écrit:
[…]But for deleting, when you delete portal row you delete current record since if you select portal row it change current record immediately. So you don't need to prevent it in portal.
As pointed out by others in this thread and others, the Master/Detail portal isn't like other portals in many ways. I dunno... I try not to get hung up on limitations and just focus on working with what we've got. Major sticking points get a Product Idea; minor points get a workaround.
user19752 wrote: I also wondered that the portal can't be sorted or filtered, at first seeing it.
The portal shows your current found set, so sorting and filtering should be done on the found set, not the portal.
As pointed out above - with the master detail portal you just need to control whether to allow deletion of the record itself.
I've found the master-detail portals great, they save loads of work, and are a really useful new feature. Scripted sorting of a master detail portal is easy, just re-sort the found set, filtering the same, just re-do the find. Saves so much work. Also, though I haven't done proper testing, they seem to be faster and more responsive than standard portals.
Hola Ben, the M/D are great, they save me time,...etc..... but !
I have a layout with M/D hidden in a slide, the idea is that the slide M/D appears only when necessary (when I call it) so I can take advantage of a greater availability of space in the layout. I use M/D but only to select a portal record, after selecting the portal record what I see in the layout is only related data, that is, if the user removes the portal row, loses the view of all related records. For the correct operation, I must be able to select a row of the portal, and prevent the user from deleting a row of the portal.
As Peter commented, I can block the portal ( Exit Script [ false ] and assign it to the portal's onObjectKeystroke script trigger ), but that also limits me in other aspects.
pd: in my 20 years as an FM solution provider, my users have never used the fmp menu, they have never used the fmp access privileges. The impossibility of removing the portal row must be an attribute of the portal. I understand that there are dissenting opinions on this subject.
.... in a schema : Master / Detail / Related
In reality, I use --> Master / Related ( it is explicit how delicate it is to delete a row from the portal )
Draco . wrote:I use M/D but only to select a portal record, after selecting the portal record what I see in the layout is only related data,
Draco . wrote:
I use M/D but only to select a portal record, after selecting the portal record what I see in the layout is only related data,
If you select a record in the M/D portal you are taken to the selected record automatically. That's how it works. The data show is *not* related data, you are physically on the record you clicked on in the portal.
This is the part that I don't follow: when you say "what I see is related data", do you mean data from the selected record? Or data from children of the selected record?
If the latter, then you're sorta not following the M/D paradigm so chances are slim you'll get what you're after. In your case then the portal doesn't show records from the current table but parents in a parent-child relationship, which is not what M/D is about.
I can block the portal ( Exit Script [ false ] and assign it to the portal's onObjectKeystroke script trigger ), but that also limits me in other aspects.
The solution I offered is really a catch-all that prevents any keystroke in the portal. If you find that this limits you, then it's as simple as changing your script to Exit [False] if the keystroke is the Delete key and Exit[True] otherwise. If you need to use the Delete Key inside a field inside your portal (which I don't think would be the case since you say that the portal is a selector) then check for that condition too.
Given the number of hoops I have to jump through to accomplish other "apparently simple" UI/UX functions, this seems like a non-issue.
Yes, that was my first trying of the new feature for use of "grid view" or "column layout". On the layout I needed showing 1/n of found count in portal, so not fit for the purpose. (1st portal row show (1..n)th records of current found set, 2nd portal row does (n+1...2n)th and so on)
I humbly suggest that if the new MD feature is not useful for your solution then just set up a self join relationship and use a standard portal. MD is a new feature which has it's pros and cons like all features. It doesn't stop you using standard portals if that is what you need. with respect I really don't see the problem here.
I think the first answer to your question, provided by PeterDoern, was the correct one.
Then, the debate of *why* are we not allowed to check this box, have more its place on Product Ideas board. And it is probably a feature easy to implement .
You can try Report a Product Issue but i'm afraid we all know the answer you'll get. As a B-plan, maybe...
Please check my just posted idea !
Retrieving data ...