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).
