I should also point out, at some point, if your requirements deviate too far from the built-in functionality of the grid, it might be easier to not use the grid and simply code your own solution.
On Thursday, April 11, 2019 at 7:24:35 AM UTC-4, Anthony wrote: > > On Wednesday, April 10, 2019 at 4:04:35 PM UTC-4, João Matos wrote: >> >> Because in my case the record is not deleted simply deactivated. >> > > Whether or not the record is being permanently deleted or simply > deactivated, it would not generally make sense to validate submitted > changes, as the expectation would be that the changes would not be > persisted. If you have a specific use case for allowing simultaneous update > and deactivation (i.e., "save these changes and then immediately deactivate > the record"), then you'll have to code that logic yourself (though I would > recommend making the user experience more clear in that case, as the > current UI and workflow does not make it clear that updates would be > persisted prior to deletion). I don't think it makes sense for that to be > the default behavior. > > >> But there are other scenarios: >> - Making additional checks before allowing the record deletion; >> > > That is what the "deletable" argument is for. It can be a function that > receives a Row object and determines if the record is allowed to be > deleted. If not allowed, (a) no delete button will appear next to that > record in the grid, and (b) the "delete record" checkbox will not appear on > the edit form. > > >> - Asking for the password of a supervisor before allowing the record >> deletion; >> > > This kind of functionality would go beyond the scope of "onvalidation" > anyway, as you would have to redirect elsewhere and start a new workflow. > You might as well code your own logic to handle this. > > >> - Making some changes to other tables as a consequence of the record >> deletion; >> - Wanting to receive an email when someone deletes a record from a >> special table; >> - Doing some house keeping or some other task when someone deletes a >> record. >> > > Better to use the db.mytable._after_delete callback for these cases. > > Anthony > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
