Also let me say that I was able to get around this problem - to suit
my purposes, but not those who need ondelete - originally with a hack
to .grid.
In the case in question, i don't really want to delete the item. I
want to remove it for the user in question. To do this, originally, I
added another parameter to the .grid class *custom_delete*, if this
parameter is nonempty, then in the switch where the delete would get
called, the custom delete gets called instead, which flags the item as
removed for this user (the item is a message between users; instead of
duplicate messaging, i just flag it as removed for one user and not
another.)
What was nice about this custom "remove" functionality, was that it
removed the item from the .grid as well instantly, like the delete
itself (some ajax magic i assume). What was not nice was that it is
that it is a change to the core, and not supported going forward
without an official change.
I settled for a custom action, and just added the button to the list,
following the instructions of another post; this has two flaws -
first, this does not remove the item instantly from the .grid like the
delete (the ajax magic is gone) and it is not properly ordered with
the rest of the buttons; namely, there is a reason why view, edit,
delete show in that order, but adding a new "remove", it appears as
first in the order, and i have not determined how to change this.
Any further information on the ondelete issue, as well as any
suggestions on my need to elegantly 'remove' would be of help.
Thanks
On Nov 17, 9:45 am, Casey Schroeder <vizqu...@gmail.com> wrote:
> Thanks Massimo,
>
> I am trying this:
>
> delmem = lambda table, itid, ct:
> auth.del_membership(auth.id_group("auth_group_1"),
> table[int(itid)].userid)
>
> SQLFORM.grid(...ondelete=delmem...)
>
> table[int(itid)] however, is returning a none type, so the userid is
> inaccessible in this way. An exception is thrown and caught, and the
> db rolls back the delete (all in local SQLite).
>
> The _dict_ of the table appears empty and I have not been able to find
> where in the table the data is buried if at all. Running the relevant
> select itself returns nothing - i made the above mentioned change
> manually, but it appears the same as that in mercurial.
>
> Thanks
>
> On Nov 17, 7:52 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > Hello Casey, Can you show us your test?
>
> > On Nov 16, 1:14 pm, Casey Schroeder <vizqu...@gmail.com> wrote:
>
> > > There may be an update on this that i missed, but can I ask if this
> > > fix is sufficient?
>
> > > I believe that the ret parameter is the effected row count, correct?
>
> > > If you just deleted the record, can you reliably retrieve it from the
> > > table and record id inondelete, i.e. before a subsequent commit? My
> > > *small* test say it doesn't work.
>
> > > Is there a way to get the record itself instead? Or am i missing this
> > > somewhere?
>
> > > Thanks
>
> > > On Oct 27, 6:46 pm, Massimo Di Pierro <massimo.dipie...@gmail.com>
> > > wrote:
>
> > > > fixed
>
> > > > On Oct 26, 4:54 pm, Bob St John <bobinco...@gmail.com> wrote:
>
> > > > > using 1.99.2
>
> > > > > in gluon.sqlhtml.SQLFORM.grid:
>
> > > > > line 1489: returnondelete(table,request.args[-2],ret)
>
> > > > > I think it should be: returnondelete(table,request.args[-1],ret)
>
> > > > > As it is now,ondeletegets (table, table, ret), whereas I believe it
> > > > > should get (table, record_id, ret) to work properly...
>
> > > > > I like thisgridmethod!
