Another button question

[murray]

I want to use the portal visibility trick to display (or not) a delete button in a single row portal based on the user's access to that record. I have everything set up and the portal visibility works perfectly however I can't get the button to delete the record I am viewing. If "Allow deletion of portal rows" is checked in the portal setup, the first record in the records I am browsing is deleted. If it is unchecked, nothing is deleted. I've tried attaching a script to the button to call an external (through the self-join) script but I can't get it to work.

It seems that I either have to have the portal automatically sort so that the current record is first, or find some other way to identify the current record as the one to be deleted (or do a find on that record's unique ID so that it is the only record being viewed, therefore the first in the portal, delete it, then reset the previous found set without the deleted record).

If anyone has any advice on this I would appreciate it greatly.

Cheers, Murray

[ESpringer]

I'm actually not sure, re-reading your post, whether you're trying to delete the MAIN record being browsed, or whether you want a certain related record to be deletable-or-not, depending on the user's identity. My guess is that you want to make this the only way to delete the currently-showing-record in your main window. Yes?

One thing I seem to recall is that with any reference at the beginning of the script to a record OTHER THAN the portal row in question can make the script "forget" which portal row it was triggered in somehow. Or rather, the script can "point" to the portal row for only one step, and after that it seems not to "grab on" anymore...

Given what you describe -- although it's not ideal, perhaps your process could involve triggering a script to "isolate" the current record before hitting the portal row button -- so that this will necessarily be the first record being browsed -- and then of course your portal row script would have to return the user to an appropriate browse set, since it would be empty after deleting the current sole record being browsed...

I always set up a scriptlet called "isolate" which goes to a self-joined "recordID=recordID" related record ONLY (an alternate process is Show All / Omit Current Record / Show Omitted), and invoke the "isolate" scriptlet in printing and other scripts to avoid potential problems with other records being browsed.

I'm still curious about making your portal button work without such a work-around, however... If it's a self-join portal *to the very same record only* iff the right user is browsing, then it shouldn't have this problem...

[Fenton]

Yes, when you surround a button with an invisible portal, the button acts on the 1st related record of that relationship. It makes sense when you think about, but still catches you by surprise.

If you allow the dialog, it will ask if you want to delete this "related record." That gives you a tip that something's wrong.

The only reliable way to deal with it is to set the current record's ID into a global field as one of the 1st steps of the script, then Exit Record. You can then later use the relationship from the global to the real ID within the script to Go To Related Record (Show is not necessary), before doing anything to the record.

Another advantage of the above is that you don't need to "allow deletion of related records" in the portal's options; 'cause you're out of the portal by the time the action occurs.

And you're free to do whatever else you want between setting the global and deleting the record (as long as you don't change the global, or leave Browse mode permanently).

[Fenton]

I should never say "only." It also works if your script has "Exit Record" before the Delete. I guess that also gets you out of the portal.

I still prefer the global Go To Related Record method however. Deletions make me nervous.

[murray]

Thanks guys,

I'll try to put this into action and see how I go. I'm still not sure how to get the button in the portal to recognise the record that is being browsed without a script initiated outside the portal.

I suppose I don't really need a portal for this - I could mask the button with a conditional calc field.

As for the deletion, it will actually involve exporting the record into a holding file first, so admin level access can review records in this file before really deleting for good.

Thanks again, I'll see how I go.

Cheers, Murray

[dbruggmann]

Hi Murray

Maybe you have already figured it out: The button in the portal doesn't have to know anything about your records, only the script you attach to it

Main.fp5.zip

[murray]

Ah Detlev,

to the rescue again. Of course your instructions worked perfectly and I was able get it working before i realised you had attached a file. I will definitely use your example to get my export script working.

Thanks very much for this - so far all of my questions have been answered.

Cheers, Murray