> > > What "wiki" are you talking about? > http://wiki.web2py.com/Home, see above comment.
> >> 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. > Ah I see now where that behavior is mentioned. Is the _and argument valid for all validators, or just IS_IN_DB? Seems that that would solve my problem. Side note, it seems like this feature of adding a validator to a list to remove the drop-down box should be a validator construction argument all on its own, it seems kind of random to attach that behavior to adding a validator to a list. Just imo. > > 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. > Huh, I can't reproduce it either. Weird. Well, good news for me, I can stop using booleans for each day of the week. > > >> 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). > Ah, I see, that's a nice feature, thanks. > > >> >> 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. > Now that I think about it, it's possible this problem actually has to do with the CAS system I'm using to authenticate; user info isn't being pulled across upon verification, so I wanted to have the user info fields computed with a function that pulls in data from an LDAP service. However, this didn't work, so I had to explicitly call a method at some point in my model code. Now that I think about it, it's possible the compute functions weren't being called because the auth subsystem was actually providing values for those info fields, albeit NULL values. Is that the expected behavior of the DAL, to not call compute on a field if NULL is explicitly passed to its column on insert?
