They don't. I have everything working (the redirection to request for supervisor password on record deletion in the grid, using a link), the checks for record deletion in the edit form also work, except for the cases I pointed out.
quinta-feira, 11 de Abril de 2019 às 12:26:34 UTC+1, Anthony escreveu: > > 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.
