Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cluge

Pages: [1] 2
1
Announcements / Re: Feng Office Mobile!
« on: August 08, 2011, 10:30:43 pm »
Have a way to automate connecting a workspace to an imap folder.

Lots of mobile apps have imap clients that work well. Some of the data is even stored in imap (see address book on nokia, or notes ah la apple ipad). Having the application be able to tie a folder to a workspace allows folks to use their mobile mail client and have their information show up in feng office in the correct workspaces.

Currently you can almost hack this functionality by creating several email accounts that are all the same except that each will ignore all folders but one and then that dumps to a workspace (kludge).  The big problem is that the kludge is only one direction and isn't well integrated (many folders = messy). Ideally if I assign an email to a workspace that I have associated with an imap folder, Feng needs to move the mail message to that folder on the IMAP server.

Respectfully,


2
Light httpd ( http://www.lighttpd.net/ )  is a much more resource light web server that uses a fastcgi interface for php.  Once your feng office starts to do a lot of traffic it's time to seriously tune apache, or look at faster alternatives. These instructions are based on a redhat install, but will work for other distributions (I will provide nginx instructions later as well). 

1. Download & lighttpd and lighttpd-fastcgi (yum install lighttpd  lighttpd-fastcgi)
2. Edit /etc/lighttpd/lighttpd.conf
            a. Uncomment mod_fastcgi module
            b. Change the server.document-root to something appropriate for your environment
            c. uncomment fastcgi.server section
3. Adjust php.ini and set cgi.fix_pathinfo = 1 and default_charset = "utf-8"
4. CD to your feng office root directory and chown -R lighttpd cache config tmp upload
5. Start lighttpd and have some fun

Gotchas:
If your using .htaccess to add any re-writing rules then you will have to take them out and put them in the server config.

If you use SSL, you need to create a PEM style key file for lighthttpd.

It has a much smaller memory footprint than Apache, and in testing the feng office felt much more responsive.  This was even after "tuning" apache.  I hope you find this usefull.

cluge

3
Things I needed to do to get notifications working after upgrade, and email working after upgrade.

1. Using local smtp or /usr/bin/sendmail no longer worked after upgrade.  Used my external server with SMTP auth.

2. Commeted out line 708 in application/models/notifier/Notifier.class.php (ie  //$mailer->close(); )

On a side note I kept getting strange errors periodically so to fix the most egregious I chown -R apache /var/www/html/opengoo/library/htmlpurifier/standalone/HTMLPurifier/DefinitionCache/Serializer

I hope this helps.

- cluge

4
Yes - after performing those DB changes, I was able to get email to work.  My issue is that cron seems to have stopped now.

5
Forgot to mention that I also had to do the same for table mail_contents

6
Installation problems / Error Creating Email account after upgrade - solved
« on: September 25, 2010, 11:57:56 am »
I was having an issue when attempting to add a new IMAP email account.  When attempting to add an imap account I would get the error ;

"Error: Query failed with message 'Unknown column 'last_error_date' in 'field list''

This install was an upgrade from previous 1.7 release.

Looking in the DB for the relevant fields I can see that mail_accounts and mail_account_users tables do NOT match what I see in the public/install/installation/templates/sql/mysql_schema.php for a new install.  Since I had no previous email setup I dropped and manually re-added the 2 tables.  This allowed me to successfully add an imap account.

I'm still playing, and the email client doesn't seem to be pulling in imap email from gmail correctly - but we will trouble shoot that later.  Not sure why the update script didn't correctly update those 2 tables. 

-cluge

7
Older versions / Re: Opengoo not working behind Proxy?
« on: November 20, 2009, 07:58:44 pm »
>I have also filed a ticket to DrayTek

Ask if they can perform an https to https proxy (not a normal config).  That would fix your issue and you would use https internally as well as externally.

cluge

8
Older versions / Re: Opengoo not working behind Proxy?
« on: November 18, 2009, 09:08:18 pm »
What you describe would be expected behavior based on the fact that opengoo thinks that your URL internally is non secure - ie http://blah_blah_blah and locally that works.  Once going through the SSL proxy the domain is actually https://blah_blah_blah - but open goo doesn't know about the secure portion.

The easy way to fix this is to not proxy the SSL requests and use SSL provided by apache & openssl.  This means that opengoo access locally and remotely would be SSL encrypted.  You will to make a small change to your open goo config once you have SSL set up.

edit opengoo_home_dir/config/config.php and change ROOT_URL

Example: define('ROOT_URL', 'https://your_actual_domain_goes_here/opengoo')

Notice the HTTPS!

cluge

9
Older versions / Re: 1.6.2 beta3 Reporting Bugs
« on: November 18, 2009, 09:00:55 pm »
Update: The reports ARE created, my issue was the filter/view I was using.  The errors still get logged but the reports are created and the function as advertised.

10
Announcements / Re: OpenGoo 1.6 BETA 3 released
« on: November 18, 2009, 01:53:30 pm »
The filtering was the issue.  I apologize.  Perhaps an "all" filter would be a good addition?

I still see errors in the log file when creating a new filter, I posted those in the bugs forum. It is creating the reports correctly.

If your in one filter (for example contacts) and create a report with another object type (say user), when you finish the report it returns you to the original filter (contacts in our example).  This doesn't show your newly created report.  I'd suggest that if you create a report that the application returns you to the filtered display of the object type of the report you just created.  That would provide a visual that the report was indeed created correctly.

Hopefully that makes sense.

Best Regards,
cluge

11
Older versions / 1.6.2 beta3 Reporting Bugs
« on: November 18, 2009, 02:15:25 am »
Upgrade from Beta 2.  My Custom report is now gone.  I now get "there are no custom reports".

PHP 5.2.9
Apache/2.2.13

No errors reported in the error log.  Clean upgrade. Attempting to re-create the report was also a failure although the gui didn't report any problems.

1. Go to reporting
2. Click "Add a custom report"

Log file produces the following errors.
#1 ERROR: Error: Undefined variable: conditions in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 65 (error code: 8)
#2 ERROR: Error: Invalid argument supplied for foreach() in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 65 (error code: 2)
#3 ERROR: Error: Undefined variable: hidWs in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 78 (error code: 8)
#4 ERROR: Error: Undefined variable: parameter_ws in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 80 (error code: 8)
#5 ERROR: Error: Undefined variable: hidTg in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 88 (error code: 8)
#6 ERROR: Error: Undefined variable: parameter_tag in '/var/www/html/opengoo/application/views/reporting/add_custom_report.php' on line 90 (error code: 8)
Time since start: 0.072946071624756 seconds

No GUI indication that there is a problem.  After adding report returns to page indication no custom reports.


Respectfully,
cluge


12
Announcements / Re: OpenGoo 1.6 BETA 3 released
« on: November 18, 2009, 01:37:58 am »
Upgrade from Beta 2.  My Custom report is now gone.  I now get "there are no custom reports". 

PHP 5.2.9
Apache/2.2.13

No errors reported in the error log.  Clean upgrade. I will post in bugs as well, but wanted people to be aware.  If you have lots of custom reports or require it, you may wish to hold off on this upgrade/testing.

13
Older versions / Re: 1.6.2 beta2 bugs
« on: November 16, 2009, 06:45:14 pm »
That worked.  Thank You.

14
Older versions / Re: 1.6.2 beta2 bugs
« on: November 05, 2009, 02:40:40 pm »
I also tried to recreate the report from scratch.  This also failed with the same error.  See below for Backtrace.


#0 /var/www/html/opengoo/environment/library/database/adapters/AbstractDBAdapter.class.php(304): AbstractDBAdapter->prepareAndExecute('SELECT id FROM ...', NULL)
#1 /var/www/html/opengoo/environment/library/database/DB.class.php(211): AbstractDBAdapter->executeAll('SELECT id FROM ...', NULL)
#2 /var/www/html/opengoo/application/models/reports/Reports.class.php(278): DB::executeAll('SELECT id FROM ...')
#3 /var/www/html/opengoo/application/controllers/ReportingController.class.php(805): Reports::executeReport('2', NULL, 0, 50)
#4 /var/www/html/opengoo/environment/classes/controller/Controller.class.php(76): ReportingController->view_custom_report()
#5 /var/www/html/opengoo/environment/classes/controller/PageController.class.php(62): Controller->execute('view_custom_rep...')
#6 /var/www/html/opengoo/environment/classes/Env.class.php(133): PageController->execute('view_custom_rep...')
#7 /var/www/html/opengoo/init.php(149): Env::executeAction('reporting', 'view_custom_rep...')
#8 /var/www/html/opengoo/index.php(9): require('/var/www/html/o...')
#9 {main}

15
Older versions / 1.6.2 beta2 bugs
« on: November 05, 2009, 01:58:55 pm »
Custom reports are broken.  The report that I used to look at latest logins dies with

"Query failed with message 'Unknown column 't.trashed_by_id' in 'where clause''

Upgrade from 1.5.3 to 1.6.2 beta2.  File uploading bug that existed in 1.5.3 is fixed in this beta release though.

-cluge

Pages: [1] 2