> > 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.
What "wiki" are you talking about? > > 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. > That is the intended behavior. The same behavior is documented for IS_IN_DB, but we should probably mention it for IS_IN_SET as well. 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. > I cannot reproduce -- can you show some code? Note, it's list:string, not listof:string. > 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. > That's the intended behavior. You can dynamically change the readable and writable attributes of any field at any time, so if you'd like, right before creating the grid, you can do: db.mytable.myfield.readable = True Elsewhere in your code, readable will still remain False (assuming that's how it is set in the main table definition). > > 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. > Can you show the code you tried? I would think it should work. Anthony
