I tried registering with the wiki in order to post some bugs I'd found, but the password field refused to validate, claiming my password was simply 'invalid'. I guess I'll just post my list of bugs here.
1. When a database field requires an IS_IN_SET() validator, you'd expect it to show up as a drop-down in forms, and normally you'd be right. However, if you place that validator within a list, even by itself, form fields revert to using a simple text field, which is definitely not ideal. 2. When using a listof:string database field type, in conjunction with a set of allowed elements (multiple being set to true), editing a record does not pull in values from the database; i.e. if I save a record with the first and third items selected, that's how it appears in the database, but when I return to edit the record, the multiselect field has no selection in it, so if I save I overwrite what I had before. 3. SQLFORM.grid contains a built-in search field, which is useful. However, it uses a form with method type GET. Normally this isn't a problem, but if the form is being displayed by a controller function that is decorated by @auth.requires_signature(), the search field dumps the user to the 'insufficient-privileges' page. The reason is that the signature token is being appended to the form action as a URL argument. Since the form method is GET, this is overridden. It should be a hidden input value, or the form method should be POST. I hacked together a jQuery fix, but it's not ideal. 4. If a field's readable attribute is marked as False, it seems that the 'fields' argument of the SQLFORM.grid constructor should override that. As in, if a certain field is marked as unreadable, but I have it in a list passed to the 'fields' attribute of the grid constructor, it seems that it should show that field regardless of database settings. I don't want to set the 'ignore_rw' flag, since that affects all fields, nor do I want to set that field to readable, since I may not want it readable elsewhere. Others' opinions on this may differ, but I think it would make sense to change this behavior. 5. Perhaps not a bug, but a useful feature that is not currently available: it would be nice to be able to attach a 'compute' attribute to extra fields appended to the db.auth_user table. I wasn't able to get them to function properly. All in all, though, it's a very simple but powerful platform to develop on, I'm pleased with what I've seen so far (just started using it this last week).
