Ingroup is used to test other users as well. It's the biggest problem. Not being able to define myLogin means I can't use default skins and sites. It's really annoying. I just want to enable a plugin and have it work.
Also, I'm thinking detailed knowledeg of BoltWire shouldnt be needed to extend it. On Jun 24, 5:09 pm, The Editor <[email protected]> wrote: > 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 > > athttp://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.
