i actually think r3372 and 3373 should go in to 2.2.. Revision 3372 at http://freepbx.org/trac/changeset/3372: drawselects() updated: - removed usage of goto_indicate an... it fixes a bug that's never been reported, that its possible to have a destination that doesn't select any radiobox (eg, if you remove a module, anything that was using it as a destination will appear blank) ivr and queues use goto_indicate yep so we'd have to update those.. but pre-release is the time to do that kind of stuff Nah, it's not _terribly_ broken and I'm getting antsy to get rc2 out 8) (being that my mum turns up here tomorrow) well i can fix those modules pretty quick.. s/goto_indicate/goto/ :p heh fuck it, throw it in they're only modules 8) grrogs, in a way you a re breaking it not fixing stick a prereq on the modules of RC2? * freepbx has quit (Excess Flood) * freepbx (n=freepbxb@65.111.165.203) has joined #freepbx-dev naftali5: ? the old way, module gets removed and the goto is gone on the next submit. new way the goto stays in custom, and goes nowhere unless the context is reinserted by hand right, but it's in that state until you try to edit it ... then you can't edit it without doing something which is kind of weird you're right on that ok, i guess your way it is there in case you reenable too, that's good or, you can also look at it like this: if the module is disabled, you can still edit the ivr that uses it BEFORE you go and upgrade/enable the module again * sb_mx has quit ("Leaving") and i guess the outcome of blank or a non-existant goto is almost the same (depends how each module handles it) well, its not blank.. its the same value ok. your way wins because it is consistent (before and after edit) the only difference is that when you edited it, it would complian also, your way you can see what it _was_ even with the module disabled * naftali5 sees the light and suddenly agrees with groogs yeah, thats also VERY useful :) especially if you have say, two modules disabled, and now your IVR is full of blanks and you have no idea what was what yes, and removing the requirement for the word custom is great well, it does mean there's the potental for chaos if they name their custom context, say, 'from-trunk' .. but the tip does suggest using "custom-" at the start ;) X-Rob: can i merge across module branches? (as in, is svnmerge setup for that?) Yep.. lemme check which way svnmerge _in_ 2.2, you get 2.1.. svnmerge _in_ 2.3, you get 2.2 so patches applied in 2.2 get merged into 2.3 cool how do you check that btw? i'm guessing svnmerge sets svn properties or something? svnmerge is black magic to me.. ;) svn pl -v . * Djeli-afk is now known as Djeli Changeset http://freepbx.org/trac/changeset/3375: Updated for changes in http://freepbx.org/trac/changeset/3372 (Tue, 19 Dec 2006 23:56:54 GMT) Changeset http://freepbx.org/trac/changeset/3376: Merged revisions 3372-3373 via svnmerge from ... (Wed, 20 Dec 2006 00:06:06 GMT) X-Rob: just found a bug in publish.pl uh? it's searching for (.+) ... but has a tag.... so it finds that, and instead of doing pbdirectory-0.3.1.tgz its making pbdirectory-2.2.tgz wups that's probably the reason for this page http://www.freepbx.org/trac/wiki/ModuleXml Changeset http://freepbx.org/trac/changeset/3377: Module Publish Script: ivr 2.5.2 (Wed, 20 Dec 2006 00:10:12 GMT) Changeset http://freepbx.org/trac/changeset/3378: Module Publish Script: queues 2.2.3 (Wed, 20 Dec 2006 00:10:28 GMT) naftali5: probably whats that other kind of validation? the one that doesnt' have syntax thats 100000 lines long RELAX NG well, anyway, that doesnt even really help for this, what we need is an xmlparser to grab the version instead of just a string parser change to ? that's going to break online modules though well, quick fix would be to ignore if it's inside if (($vers == "unset") && (/(.+)<\/version>/)) { $vers = $1; } (though i'm not sure if thats valid perl within the while() thing like that?) ..and then make sure that version is before ls oops X-Rob: can you fix it? yep, I'm just sitting here waiting for a phone call at the moment (day is insanely bad) Changeset http://freepbx.org/trac/changeset/3379: Misc apps module (Wed, 20 Dec 2006 00:30:28 GMT) Changeset http://freepbx.org/trac/changeset/3380: Module Publish Script: miscapps 0.1 (Wed, 20 Dec 2006 00:30:53 GMT) fucker. I haven't swiched my freepbx-modules and just got a 500 So.. no chance of a hexadecimal Device ID? * Djeli runs! not yet * Djeli ducks! * Djeli narrowly misses being decapitated by a flying TDM400P. Djeli: why? I always seem to suggest features about 10 minutes before Rob releases a new version. a while ago i was actually suggesting we default to alphanumeric device ids (d201) in DEVICEANDUSER mode, just to make the distinction between users and devices a bit clearer.. Djeli, not his time, though, you've been pushing this for _days_ s/days/months/ Well, pushing is a strong word. :) what is the purpose? Its just the final piece to my auto-provisioning module provisioning .. ? If the SIP devices = Mac Address, then http auto-provisioning of Polycoms is easy oh, interesting idea .. I have all the provisioning stuff done (in modules, so you can snap-on additional device types) though... no, i like mac address a separate field still It'll only work in device/user mode Changeset http://freepbx.org/trac/changeset/3381: Module Publish Script: pbdirectory 0.3 (Wed, 20 Dec 2006 00:34:09 GMT) Changeset http://freepbx.org/trac/changeset/3382: Fix <version> being incorrectly picked up. (Wed, 20 Dec 2006 00:36:22 GMT) because if a phone dies, you can just swap it You see, I'd create a new device for that, because it is a new device