OpenBiblio

What differentiates the stuff under tools from the stuff under admin? I originally made the tools directory for development tools that would not be shipped with the system, like release and testing scripts. But there's now some user functionality in there as well. I think this should either go back under admin or be put in a directory of it's own -- I need a place to put scripts that don't go in the release, and that's been called 'tools' since 0.5.something. Micah

I think Fred mentioned something about not clogging the admin screen to much, and only leave basic settings there. Therefore everything that is a bit more advanced (like the multiple site) is under tools. However, I was not aware that the tools was for special cases. I have no problem either with an extra 'Advanced - admin' group or moving them all to admin. I think it is important though that it is clear that they are settings so people can find them (which might be a bit of an issue in the current location/set-up under tools)

The admin menu is pretty cluttered. We could do a hierarchy, though. My leaning would be to keep everything under admin, but organize it better. Changing settings is an administrative function, after all. It will take a bit of thought to figure out the most logical way to arrange things. I've added a low-priority item to the tracker. Micah

I created the tools menu item in response to you (Micah) statement that you did not want to add stuff to Admin that was seldom used. My idea was to place in tools those things that an installer would want to use, but that the administrator would seldom even consider. In fact I had the intent to create a new role of installer (with own pass word) so that tools wouod not even be visible to the administrator. Aside from all that they could be easily combined I suppose. Fred p.s. very busy with road culverts field work, Town mapping work, home furniture building, LAN installation at relocated library, etc. This and fall are the only time I get to do this stuff, so you will not see much of me until weather gets too hot, or the bugs get too annoying - perhaps late May or so.

What I meant by that statement was that features few people use should not be in the system at all, not that they should be kept in some other area. I want OpenBiblio to be a small library system that a single programmer can easily understand in full. The current 1.0 code is over 42,000 lines now -- not counting installation SQL files. 0.6.1 was just under 30,000, and I thought that was too much. My goal is to have a small, simple, solid, secure base system that is easily modified and extended to be exactly what a given library needs. If at all possible, that simple base system should not be larger than 30,000 lines. This isn't just about lines of code, either. Every feature adds conceptual weight to the system. I don't want a "feature-rich" library system. That's Koha or Evergreen. I want a library system with just the right features. I think we should remove any feature that won't be useful to a majority or at least a large minority of our target audience. So who's that? I'm aiming at school libraries and small-to-medium public libraries. Probably the biggest thing this means removing is the booking/reservation system. I wrote it, and I have support contracts with a few libraries that use it, but it shouldn't be in the main distribution. It should be a plugin. It's useful, even necessary, to some libraries, but most school and public libraries won't use it, so it needs to go. This clean-up isn't going to happen tomorrow, but I do intend it to happen before 1.0 is released. Hopefully, by the time the heat and the bugs chase you back inside, I'll have the circulation section mostly done so you can see what I'm talking about. Incidentally, I think the idea of an installer password is good, but anything like that should probably be under /install and not even appearing on the main menu. That's probably a good place to put plugin management. Micah