SOC Progress on "User Manager for SWAT (Samba 4)"

S P sree314 at gmail.com
Mon Sep 4 18:02:28 GMT 2006


On 9/4/06, tridge at samba.org <tridge at samba.org> wrote:
>We really need
> a better error reporting mechanism!
Seconded. Quite some time spent chasing an encoding  problem where I
sent an array instead of an object.

> I noticed that the user browser window wouldn't grow or scroll
> correctly. It also starts off quite small (at least on my screen) but
> maximising it doesn't work well.

Yes the list size is hardcoded. Known problem, as setting it to "100%"
causes problems with the title bar of the qooxdoo window widget. Also,
maximizing it will increase the size, but restoring it doesn't work
then. I think listview is known to be problematic, and I think 0.6 has
a better control.

>I had a look at how it works, and
> what struck me is that the js code in userbrowser.js is a bit too hard
> coded, and not abstracted enough. It does things like directly
> constructing a QxListView(), a QxBoxLayout(), menu, window etc. That
> works ok for a demo, but I think it would be better to construct a
> higher level widget handles all the details for a multi-column list
> with callbacks attached to a set of ldb records, and keep all that low
> level gui code quite separate from userbrowser.js. The userbrowser.js
> code would become much simpler, and would just be a consumer of this
> widget, just passing in a list of attributed that can be read/written
> etc. Deryck might have more comments on the best way to approach this?

Well, userbrowser was supposed to be exactly what you're describing,
but guess it didn't turn out that way :) As described in a earlier
post, I'm still trying to find out the Right Way to do this.

> I played a bit with changing user properties, and sometimes got an
> error when doing things like changing the user description. The
> strange thing is that the description did change, even though it
> displayed an error. It seemed to be a problem with strings turning up
> as object pointers and trying to commit those into the database?

This seems to be a bug somewhere. It doesn't occur in TP2 which I also tested.
But note that the latest revision of the code will fail in renaming on TP2.

> It also showed another problem with error reporting. The usual error
> message was "Could not update properties" in a alert box, but no
> reason was given for why the properties could not be updated. We have
> to make sure that we propogate any ldb errors back to the user, so
> they at least have a chance of working out why something went
> wrong. Ideally we'd even have a little 'details' button on the error
> display which would expand to the ldif we were trying to use in the
> ldb operation (presuming it was an operation that takes ldif, like a
> modify).
>
[SNIP]

Yes, I should've done this, the show LDIF idea via details button idea
is cool, and gives me a reason to use qooxdoo widgets instead of js
alert boxes.

> One thing that puzzles me is the fact that when I got the error
> message from a properties change, it did still change at least some of
> the properties (ie. when I did a refresh the change showed up). That
> is bad! It means something is going wrong with the transaction code,
> either in how we are calling it, or in the ldb/tdb code itself. The
> point of transactions is that either it all works, or nothing changes,
> so to see something partly working worries me! We need to look into
> this.

I'm using nested transactions here. So perhaps this is by design? I've
noted this in the source (usermgmt.esp).

Sreepathi Pai
___________


More information about the samba-technical mailing list