Errors using BulkExtensions

Hi,

I have installed the BulkExtensions module from the tarball (changed the owner of the directly and files to be asterisk:asterisk) and enabled it in FreePBX.

I now get the follow errors at the top of of every page:

Warning: main(modules/dictate/functions.inc.php): failed to open stream: No such file or directory in /var/www/html/admin/modules/bulkextensions/functions.inc.php on line 4



Warning: main(): Failed opening ‘modules/dictate/functions.inc.php’ for inclusion (include_path=’.:/usr/share/pear’) in /var/www/html/admin/modules/bulkextensions/functions.inc.php on line 4


Warning: main(modules/languages/functions.inc.php): failed to open stream: No such file or directory in /var/www/html/admin/modules/bulkextensions/functions.inc.php on line 5



Warning: main(): Failed opening ‘modules/languages/functions.inc.php’ for inclusion (include_path=’.:/usr/share/pear’) in /var/www/html/admin/modules/bulkextensions/functions.inc.php on line 5

Looking in the directory tree, there are files in the location specified. If I disable the module the errors go away.

Does anyone know what is going on?

Thanks

Graham

From where did you get bulkextensions?

The proper way to install it is to download it from here http://freepbx.org/trac/browser/contributed_modules/release/bulkextensions-2.5.0.4.tgz
Save the file to your desktop, then go to Module Admin, click on Upload module, browse for the file bulkextensions-2.5.0.4.tgz then click on Upload.

The module can now be seen in Module Admin, enable it there and test to see if it now works.

Hi,

I got it from the repository and expanded the tarball directly on the server. I have just tried removing the module manually and adding via the upload module button and I get the same result.

I am using FreePBX 2.5.1.5 if it makes a difference on an old Trixbox install.

Graham

Hi,

I have just tried BulkDID and that functions fine, so it is something specific to the bulk extension module.

Regards,

Graham

Original message removed by author. mickecarlsson has committed version 2.5.0.5 (an “official” release, as opposed to the package that should not have been posted in Ticket# 3584) and it can be obtained at http://www.freepbx.org/trac/browser/contributed_modules/release, so the original post here is moot.

Graham, you say that the files it is complaining about do exist, so my question would then be, do those files possibly have improper permissions or ownership? Now and then a problem like this comes up because permissions and/or ownership are wrong somewhere (such as a module not “belonging” to asterisk/asterisk for user/group). Just a shot in the dark.

Graham, can you verify that you have modules Languages and Dictation installed. Without them you will get the error above.

wisedoldowl, I am doing this on my spare time and I am testing the code so that it won’t break things. The module will be released when it is ready.

To avoid confusing you even more I have removed the attached file in the ticket that was uploaded with a version number.

ping me at #freepbx-dev later today so that I can explain the publish process for a module.

wiseoldowl, a released module is a module that resides here:
http://support.freepbx.org/trac/browser/contributed_modules/release

An ongoing development of a module takes place here:
http://support.freepbx.org/trac/browser/contributed_modules/modules/bulkextensions

To see what have changed and by whom you go here:
http://support.freepbx.org/trac/log/contributed_modules/modules/bulkextensions

If you go the the last link you will see comments like

10/24/08 05:43:54, sasargen, add table.csv for bulkextensions to svn

That indicates that sasargen added code and some new features to the module on October 24th 2008.
Then he added some more code to it November 12th 2008 and closed one feature request.

Here he published the module. That “bumps” the version number from the previous version 2.5.0.3

Module Publish Script: bulkextensions 2.5.0.4

I added permit/deny fields that 4Colo provided a patch for on March 18th 2009. Then there was a bug mentioned in the forums that I added April 19th 2009.

After that you decided to close the ticket without any knowledge on how the system works by submitting old code that reverted all my previous changes. I reverted those.
You then “bumped” the version and messed up things again. I reverted those as well. I then explained to you on #freepbx-dev how the system works.

Today I coded a small fix so that if a template is uploaded without deny/permit values it adds the default “0.0.0.0/0.0.0.0”.
When I tested the code with a rather large import I discovered that the module put out some error in a FreePBX 2.6 beta.
I debugged the code and found out that there were more fields added to the GUI that needs to be taken care of. I have to check with the project leader if those changes will be ported back to 2.5. If that is so I must wait until those changes are published to be sure that bulkextensions will work on both 2.5 and 2.6.

I do not “own” bulkextensions, but I work on localizing it so that other can benefit from it.
The only confusing here is that you don’t understand the process between “work in progress” in svn and a released version.
When a module is considered fixed from a bug ticket or when a developer have made such changes that he feels that it can be published it will be packaged together in a “publish” that “bumps” the version number and put the module in the released directory. From there if it is a supported module it will show up in FreePBX as a new version. The contributed_modules are somewhat different that requires users to download the module then upload it manually to the system.

There is no need to attack me like you do in the previous post. If you feel like complaining, please do so in a private PM or ping me on irc.

I am here to help in the best way I can think of. But please understand that I do this on my spare time.
The reason for not working on the module was that my lovely daughter graduated last week and I prioritized that.

mickecarlsson, you wrote:

[quote]
wiseoldowl, a released module is a module that resides here:
http://support.freepbx.org/trac/browser/contributed_modules/release

An ongoing development of a module takes place here:
http://support.freepbx.org/trac/browser/contributed_modules/modules/bulk

To see what have changed and by whom you go here:
http://support.freepbx.org/trac/log/contributed_modules/modules/bulkexte

If you go the the last link you will see comments like

10/24/08 05:43:54, sasargen, add table.csv for bulkextensions to svn

That indicates that sasargen added code and some new features to the module on October 24th 2008.
Then he added some more code to it November 12th 2008 and closed one feature request.

Here he published the module. That “bumps” the version number from the previous version 2.5.0.3

Module Publish Script: bulkextensions 2.5.0.4

I added permit/deny fields that 4Colo provided a patch for on March 18th 2009. Then there was a bug mentioned in the forums that I added April 19th 2009.

After that you decided to close the ticket without any knowledge on how the system works by submitting old code that reverted all my previous changes. I reverted those.[/quote]

I fully agree with your narrative to that point. I was simply trying to be helpful by including the patches from Ticket #3584. As you are probably aware, I’m really not much of a coder (give me an hour and I might figure out how to write one line of code, and even then it probably won’t work) so now and then I try to help in whatever way I can. I had no idea you’d made any changes or updates; all I knew was that in the approximately three months or so since C4colo had submitted his fix to add the permit/deny fields, they had not made it into the release version of the module. I felt it was rather important that these be included, so I went ahead and added them. You are correct in saying that I did not know where I should be looking to discover that you had already made changes - silly me, I thought that if any significant changes had been made they would have been published and the version would have been updated. So, I screwed up, and I admit that. I will add that you were none too nice about pointing that out - yes, you did educate me a bit but you also made me feel as if I’d peed in your personal wading pool. Oh, well.

My issue then, and now, is that anyone going to the site with the released modules repository at http://support.freepbx.org/trac/browser/contributed_modules/release still cannot get a version that supports the permit/deny fields. For reasons that are totally unfathomable to me, you don’t seem to want to release C4colos’s patches until until you have finished some additional work on the module. But until you do, anyone who uses that module doesn’t get a complete backup of their extension settings, if they have used the permit/deny fields. I fail to see what permit/deny has to do with the language modifications, but if you are claiming “ownership” of the module then it’s your call. However, and this is where I’m coming from, there was NO indication anywhere that you expected others to keep their hands off. So someone like C4colo or me comes along, attempting to be helpful, and gets ignored or bawled out for their efforts.

Where we disagree starts here:

I’m still not understanding how I “messed things up” by bumping the version. I did some (very minor) work on Rob’s routepermissions module and bumped the version whenever I made an edit there, and nobody said a word about that, yet for some reason you seem to feel that version numbers are like gold coins and are precious to come by. I just don’t understand that way of thinking. My feeling at that point was that you reverted the version because you were trying to prove a point, that you were in charge and that I should stay the heck out of your code and away from your module. Again, that’s fine, but in our subsequent discussion to told me you’d at least release a version with C4colo’s mods in a day or two (again, we’re talking about patches he had submitted some three months earlier!). And you didn’t do that. I understand, you were busy. Meantime, there’s a three month old version of 2.5.0.4 on the “released modules” site, but if someone knows enough to visit the site at http://support.freepbx.org/trac/browser/contributed_modules/modules/bulkextensions they can get a newer version WITH C4colo’s patches and some additional things you’ve added, but even then it will still be version 2.5.0.4.

And now, I guess to further prove that nobody should touch that module but you, you’ve actually removed the patched version that C4colo had uploaded as version 2.5.0.5 - apparently HE didn’t understand how the process works, either. And yet you say,

And that’s great - we appreciate that. Seriously, far better you should be working on that code than me! But here is the problem I have - if you don’t “own” it, why are you the only one allowed to determine when and under what circumstances the version number should be bumped? And why is it that when someone contributes a working patch, you seem to be the only one allowed to determine when a version that includes that patch gets added as a “released” version? Honestly, I’m not trying to be a jerk about this, I just think these things should be clarified. If I don’t understand how the process works, I’m willing to bet there are others who don’t either.

I’m sorry if you feel like you were attacked, but you had said you’d release a version with C4colo’s patches (at least) in the next day or two, and that was the only reason I let the issue drop then. I do, however, feel there are more important issues at play here - I even submitted Ticket #3719 trying to get some clarification on this (and almost immediately had another developer suggest that I should “f off and die” in the IRC channel - so much for being receptive to constructive suggestions). So you are not the only one who feels “attacked” here - if you remember the morning that I made my mistake, you were pretty condescending to me at the time. Although in my mind this is not a case of trying to “get even” or anything (really, I just would like to see this process defined in such a way that it makes sense, and I think bumping a minor version number when you change a publicly-accessible version of the module is an important component of that), I will say that sometimes “what goes around comes around” and if you treat me discourteously, I might not feel quite as inclined to take great care not to upset you in the future.

Having said that, I hope we can put this behind us and move on. And, congratulations on your daughter’s graduation, I’m sure you must be very proud of her!

Yes they do. It is in their backup when they use the Backup & Restore module.

OK, I will try to explain that s l o w l y…

When there is work in progress for a module (or core) it is in svn. When it is in svn there is absolutely no reason for bumping version numbers until the work is considered ready for release. When it is, a special tool is run against the work and you decide which revisions should go into the released version.
The tool build the module, updates the version number and place it is the released directory.
You can actually decide to not let a revision go into the module. So in this case with bulkextensions, when it is ready to be released I will notify Philippe that he can publish the module with revisions r7542, r7579, r7811. I do not want the revisions r7778, r7779, r7780 and r7781 go into the release.

So, work in svn are considered unreleased code, alpha or beta. And when it is in svn you should never change version number until it is published.

Well, I did have a look at that, and I am sorry to say it wiseodlwol, that is not the correct way to do it.
If you go to http://support.freepbx.org/trac/log/contributed_modules/modules/routepermissions?rev=7812 and look at all the changes that Rob have done you will find that he never touches module.xml to change the version number.

No, they cant, what they can get (if they download it from svn) is a beta not ready for release. Remember, in svn it is work in progress.
You can use this code to get the latest changes down to FreePBX, I do as I have a couple of machines in vmware where I test all things before committing it back to svn.

I am not, it is the publish tool that does that.

Guidelines for svn are here http://freepbx.org/trac/wiki/Guidlelines
How to pull the latest development code http://freepbx.org/trac/wiki/SvnPull
Working with SVN http://freepbx.org/trac/wiki/SvnTips
Preparing a Release Tarball: http://freepbx.org/trac/wiki/FreePbxRelease

Well, I was, because if you notice the changes that you did removed a lot of my work that I have done for localization, r7778
If you look at all the text with red background, all that was removed when you committed the code back to svn.
All text with green background is what you added. So, yes I was upset, I reverted those changes and let some steam out on irc.
I explained to you that you must do a svn update before doing a svn ci to avoid overwriting code that another developer might have added to the module in the mean time.

I think that we can continue this discussion in irc where I can explain more in detail the surroundings in svn and how it works.

Finally,
Yes I am very proud of my daughter.

Hi,

Yes, the first thing I checked was the ownership of the files and they are the same as other modules in the same directory tree.

Thanks for the suggestion.

Graham

Hi,

I don’t have those modules installed, so that would explain it. Is there a particular dependancy on functionality in those modules as it appears to work without them, just puts up the annoying errors.

Is there any functionality in the modules framework for specifying such dependancies?

Graham

[quote][quote]
But until you do, anyone who uses that module doesn’t get a complete backup of their extension settings
[/quote]

Yes they do. It is in their backup when the use the Backup & Restore module.
[/quote]

Now hold on a minute here - that’s simply not true. The last “released module” in http://support.freepbx.org/trac/browser/contributed_modules/release was posted on 03/12/09 by p_lindheimer, and it included changes up through changeset 7497. You didn’t add permit/deny from Ticket #3584 until Changeset 7542 on 03/18/09 (almost a week later). And when you did that, you did not add C4colo’s changes separately, but you bundled them with some of your own localizations, thus making it impossible for me or anyone else to request Phillipe to publish Bulkextensions with C4colo’s changes alone, as I might otherwise have been able to do, given his comments on my Ticket #3719.

So I stand by my original comment - anyone who downloads version 2.5.0.4 from the release repository won’t get the benefit of C4colo’s patches, which means they won’t be able to backup and restore the permit/deny fields.

And just for future reference, how about in the future, when you add someone else’s patches you don’t bundle them with your own, so that those of us who may want those features to be made available earlier than whatever your release schedule might be can request that they be published? Note I’m saying that based on your previous assertion that you don’t “own” the module - therefore C4colo’s additions should have been placed in their own changeset.

[quote][quote]
I’m still not understanding how I “messed things up” by bumping the version.
[/quote]

OK, I will try to explain that s l o w l y…
[/quote]

…as you would to a complete moron. Got it.

[quote]When there is work in progress for a module (or core) it is in svn. When it is in svn there is absolutely no reason for bumping version numbers until the work is considered ready for release. When it is, a special tool is run against the work and you decide which revisions should go into the released version.
The tool build the module, updates the version number and place it is the released directory.[/quote]

And just where, pray tell, was THAT documented? I looked through the four links you sent me and nowhere that I could find does it say “don’t change the version number.” What was I supposed to do, get out my pointy hat with the stars on it and my crystal ball and intuit that this is how things are done? This is one of my big issues with the FreePBX development community in general - you have all these special procedures that you take for granted but when anyone else breaks an unwritten rule, you treat them like a complete idiot.

[quote]You can actually decide to not let a revision go into the module. So in this case with bulkextensions, when it is ready to be released I will notify Philippe that he can publish the module with revisions r7542, r7579, r7811. I do not want the revisions r7778, r7779, r7780 and r7781 go into the release.
[/quote]

And part of my point here is that C4colo’s changes which are included in r7542 should have been published three months ago when they were submitted, not sat upon until you got all of your other stuff done - again, assuming that others are allowed to work on this module other than you. You can’t have it both ways, either you claim ownership of the module or you don’t, but if you don’t you shouldn’t be standing in the way of changes made by others.

Well, again, please show me the page where that’s documented. I’m not saying you’re wrong, I’m just saying that if it isn’t documented then you have no business jumping all over someone as rudely as you jumped all over me. And, if it’s only documented in the middle of some obscure page that no one would ever look at unless they were deep into the development process, that shouldn’t count either.

[quote][quote]
I did some (very minor) work on Rob’s routepermissions module and bumped the version whenever I made an edit there, and nobody said a word about that,
[/quote]

Well, I did have a look at that, and I am sorry to say it wiseodlwol, that is not the correct way to do it.
If you go to http://support.freepbx.org/trac/log/contributed_modules/modules/routepermissions?rev=7812 and look at all the changes that Rob have done you will find that he never touches module.xml to change the version number.
[/quote]

And yet at the time nobody said a single word to me that it was wrong. And if you look at module.xml in the released version, all my version changes are still there, so obviously Phillipe had no problem with me changing the version, otherwise I’m sure he would have reverted the changes and/or said something to me. It’s YOU who are being such a hardcase (believe me, there are other words I could have used there) about this.

[quote][quote]
they can get a newer version WITH C4colo’s patches and some additional things you’ve added, but even then it will still be version 2.5.0.4.
[/quote]

No, they cant, what they can get (if they download it from svn) is a beta not ready for release. Remember, in svn it is work in progress.
You can use this code to get the latest changes down to FreePBX, I do as I have a couple of machines in vmware where I test all things before committing it back to svn.[/quote]

Okay, fine, it’s a beta. As for “not ready to release”, I will just point out that C4colo’s changed version (the one you took it upon yourself to delete from his ticket) WAS ready to release. Maybe not through the “official” third party repository, but it was definitely ready for use.

Gee, I wonder why some third-party developers are choosing to eschew the official third-party repository and simply put their FreePBX modules up on their own sites?

[quote][quote]
why are you the only one allowed to determine when and under what circumstances the version number should be bumped?
[/quote]

I am not, it is the publish tool that does that.
[/quote]

Okay, and just for the record, I will say that in my opinion that’s the wrong way to do things. If you look at most other projects, even unreleased versions get their own version numbers. If FreePBX wants to stand pretty much alone in the software world as only doling out new version numbers to “release” versions (as if version numbers were some sort of scarce resource) then there’s nothing I can do to change that, but I will at least have the courage to tell you that I think you or anyone else who thinks it’s a good idea to reserve version numbers for releases only is just wrong. And it especially causes problems for those who may get a version of the software using SVN, because it makes it more difficult to know which particular version anyone may have - you can’t just look at the version number on the module.

So stone me for saying it if you like, but this just isn’t the right way to do things.

[quote][quote]
I just think these things should be clarified. If I don’t understand how the process works, I’m willing to bet there are others who don’t either
[/quote]

Guidelines for svn are here http://freepbx.org/trac/wiki/Guidlelines
How to pull the latest development code http://freepbx.org/trac/wiki/SvnPull
Working with SVN http://freepbx.org/trac/wiki/SvnTips
Preparing a Release Tarball: http://freepbx.org/trac/wiki/FreePbxRelease
[/quote]

Thank you for those references. As I noted above, I could not find anywhere that it said not to bump the version number. Of course, it would be nice if there were links to this sort of documentation in some document.

I think FreePBX could really benefit from a document entitled something like, “So you want to write a FreePBX module - here are the essentials you need to know” (okay, so the title could be shortened, but you get my drift). The problem is that the developers (well, SOME developers) seem to take for granted that others know everything about the development process that they do, when nothing could be further from the truth. And every time I think I have some part of it figured out, it turns out I’m completely wrong.

[quote][quote]
if you remember the morning that I made my mistake, you were pretty condescending to me at the time
[/quote]

Well, I was, because if you notice the changes that you did removed a lot of my work that I have done for localization, r7778
If you look at all the text with red background, all that was removed when you committed the code back to svn.
All text with green background is what you added. So, yes I was upset, I reverted those changes and let some steam out on irc.
[/quote]

Right. And it never even occurred to you that I was just trying to be helpful and to clear a ticket out of the ticket system, something that I had THOUGHT (up until that point) that the developers wanted some help with. I had NO intention of stepping on your toes, but that didn’t stop you from acting like I was either being malicious or stupid. Okay, maybe I WAS ignorant of the process, but you could have pointed that out in a different manner.

Yes, and I admit I should have done that, but again it never occurred to me because I was just going by the version number. You make mistakes, you live and learn, and you hope that no one bites your head off in the process. But I get the feeling that you are sort of a control freak (in part because you are so uptight about spelling errors) and you just can’t let anyone else live and learn, you have to lay down the law as if they were your subordinate - or your child. You just happened to pick the wrong person to vent on when you started in on me.

You know what, this whole situation (and the “f off and die” comment in the IRC channel yesterday, which I know wasn’t by you but still was uncalled for) has left a bad taste in my mouth for the IRC channel right now. I need a few days to cool down - if I were to talk to you in IRC right now I just don’t think it would be a very productive discussion.

I just want to say that you guys may not see it but you do sometimes treat would-be developers (and others who may wish to participate in some way) like crap when they don’t know everything you know. I see that sometimes it goes both ways (thinking of one guy in particular) but you really don’t give the potential developer much to go on. In particular there is a real lack of accessible, clear documentation that explains the whole process. And by “accessible” I mean that it’s where anyone can find it, not just those who may have a particular page bookmarked. I know there are things I am ignorant about and that I make mistakes, but to put it in perspective, suppose you were offered a chance to play a game, but part of the game was that you had to discover the rules of the game as you went along, and if you break a rule they shoot you! Not may people would choose to participate under those circumstances. I know I certainly won’t be very inclined to try to help out in any way after this.