This is possible, but I'm not sure I see why it is necessary... Why not simply map the login/logout (and register) functions to your own custom functions. That's actually why it is not a core function. I wanted to give full flexibility to the admin. The only thing you need to do is have your login/logout functions set/clear the appropriate session values. Once that is done you should have no problem with any of BoltWire's internal systems working.
Let me know if this is not clear how to do, or why this can't work. I generally reserve the myBOLTfunctions to system functions not specific commands, functions, conditionals and the like, as they are easily customizable already... Cheers, Dan On Wed, Jun 9, 2010 at 8:51 AM, DrunkenMonk <[email protected]> wrote: > Due to the diplomatic winds blowing in sweden, I find myself needing > to extend my book-keeping system into a full fledged membership > database for some 10,000 students. > > Now, since I'm using a boltwire site mostly as as a front-end to the > underlying databases, I find myself needing to abandon boltwires' > login system in order to use the member-database directly. > > This isn't difficult. > > What is, however, annoying is that I cannot do this in a way that will > be transparent to boltwire. > > I would have to use my own ingroup, login, logout functions, and the > rest of the site will have to be re-written in order to obey these > memberships. Further, the auth-functions (read, write) will not obey > the new, real, group memberships. > > This could be fixed with the old myBOLTfunction concepts. > > Thus, if possible, I would like BOLTingroup to be given the following > line of code: > > > if (function_exists('myBOLTingroup')) return myBOLTingroup($group, > $id, $new); > > I would also prefer if the BOLTXlogin command could be changed into a > wrapper, moving the actual login commands into > BOLTlogin($id, $password, $member) > (pick out the relevant strings from $BOLTarray in the command, send > the result into the real login function) > with an available myBOLTlogin function option. Given how brilliantly > adaptable BoltWire is in other respects, this change would make sense. > > The BOLTXlogout command would be changed in much the same way. > > Quite apart from making my life a lot easier, login and logout feel > like they should be system functions to me. Much like how the > BOLTarray shouldn't be needed in anything but commands, the session > information and other global variables should be written to only in > logical places, namely, the engine. Of course, that's just me being > pedantic. > > -- > You received this message because you are subscribed to the Google Groups > "BoltWire" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/boltwire?hl=en. > > -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
