FOP2 Community Forum

layout is fluid, if you vary screen resolutions, widgets will follow and rearrange. Are you opening FOP2 always maximized? or with different screen sizes?

And the new version does work much better in showing the extension numbers during an internal calls and correct callerid information in general. Thanks for the update.

No idea, I have not tested it. however, as far as I know, systemd should use the regular init scripts...in any case, an init script should not prevent fop2 from working.

In my case, I forgot to put in what the permissions were! Once I put in "all" for permissions, the action buttions showed up. I thought I better post the solution! Even, as simple as it is. Thank you for your work!

Never mind, I see that there was a partial commit on the manager files. I will fix that for the final 2.29.01 release.

The debian version has the newer html/js files for sure. Most probably you saw an old/cached version from your browser, but not the newer files installed from tarball. Clearing your browser cache should have fixed that issue and showed you the newer login et all. I am online at the live help now if you want to chat. Best regards,

I must have been confusing it with the FOP2Admin module that I installed via the Freepbx module. Thanks for the help. Gene PS: Thank God for Kristina Kirchner and the fight Argentina is waging against the "vulture funds"! Your President is a blessing to your country, its people and the world community. America needs such a President!

All is going well today after the change you suggested. I have done many mod reloads today for many reasons and no problem with the FOP2 panel. Thank you Nicolas Gene in Virginia, USA

In this particular instance/installation: Unfortunately, my new version of Debian (Wheezy 64bit) and the old version of FOP2 (2.26) were not compatible. So I had no chance of installing the older version, running the license, and then upgrading to 2.27. I had upgraded my old Debian 6 (32 bit) to FOP2 (2.27) but the upgrade to 2.27 was not recognized on the new install. If you have the same problem that I had, make sure you let Nicolas know of this particular problem, so he can get you up and running. Thank you Nic for your help--again!

Not sure if I understand your problem exactly... however, mute events are just mute events. There is no way to find out who muted or how it was muted. We just receive a mute event. So, it is not possible to find out if was an admin or an user. To make things worst, the new confbridge does not even send any mute status on participants over AMI. As the next version will support confbridge, it will be partially working regarding mute states becaue the AMI events are not verbose enough. Best regards,