Thread: Anyone know a good opensource CRM that actually installs with Posgtres?
I hope that someone has cracked this one because I have run into a brick wall the entire week and after 3 all-nighters with bad installations, I would appreciate hearing from others! I am looking for a decent OpenSource CRM system that will run with Postgres. SugarCRM seems to be the most popular but it's MySQL-centric and its opensource parts are very restricted. vTiger is also mySQL-centric. I thought that I had a corker of a system with "centricCRM" but when it came to actually installing it, I am 48 hours down and hacking through screen after screen of installation errors. Basically, it relies way too much on ant and Java tools. Nothing against Java but my experience with ant used for installing PG schemas is a dismal track record of error and frustration. centric CRM is no exception. Frankly, it just doesn't work and after trying to hack out the ant into a PG script I have decided to give it up as a bad job. XRMS promises to run on PG but... it doesn't. The core system is fine, but useless without the plugins. The Plugins are mySQL-specific again, I spent several all-nighters previously hacking through installation screens attempting to convert mysql to PG, making software patches... you get the picture. XLSuite looks very promising. Awesome interface, looks great... only it's just not ready yet. It is a year away from being at full PG production level. Compiere doesn't support PG. OpenTAPS the demo won't even work. And it's US-centric whereas we are in the UK. A pity that it's so very much tied to the US as it could be very good. I have tried numerous other CRMs but all the same - either don't run on PG, claim to but in reality don't or are simply pre-Alpha and not ready for production use. So if anyone has actually cracked this, please let me know! I really need a good CRM. It has to be OpenSource, not just out of principle, but we need to integrate it into an existing business with established inhouse software so we need to be able to customise the code. Thanks, Brad
Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a > brick wall the entire week and after 3 all-nighters with bad > installations, I would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. Not a recommendation, coz I haven't actually used it, but you might try Drupal, if you haven't already. I've seen Drupal work OK, & it claims to support Postgres. Brent Wood > vTiger is also mySQL-centric. > > I thought that I had a corker of a system with "centricCRM" but when > it came to actually installing it, I am 48 hours down and hacking > through screen after screen of installation errors. Basically, it > relies way too much on ant and Java tools. Nothing against Java but my > experience with ant used for installing PG schemas is a dismal track > record of error and frustration. centric CRM is no exception. Frankly, > it just doesn't work and after trying to hack out the ant into a PG > script I have decided to give it up as a bad job. > > XRMS promises to run on PG but... it doesn't. The core system is fine, > but useless without the plugins. The Plugins are mySQL-specific again, > I spent several all-nighters previously hacking through installation > screens attempting to convert mysql to PG, making software patches... > you get the picture. > > XLSuite looks very promising. Awesome interface, looks great... only > it's just not ready yet. It is a year away from being at full PG > production level. > > Compiere doesn't support PG. > > OpenTAPS the demo won't even work. And it's US-centric whereas we are > in the UK. A pity that it's so very much tied to the US as it could be > very good. > > I have tried numerous other CRMs but all the same - either don't run > on PG, claim to but in reality don't or are simply pre-Alpha and not > ready for production use. > > So if anyone has actually cracked this, please let me know! I really > need a good CRM. > > It has to be OpenSource, not just out of principle, but we need to > integrate it into an existing business with established inhouse > software so we need to be able to customise the code. > > > Thanks, > > Brad > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Kenneth Downs
Date:
Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a > brick wall the entire week and after 3 all-nighters with bad > installations, I would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. > Bradley, I've got about 2.5 out of 3 of what you are looking for, perhaps it might work out for you. We have a GPL database application framework that we have used for a handful of CRM-style applications (links below). It runs on Postgres, is completely GPL, and is written in PHP. Now the bad news :) We have only crude CRM stuff, and you may end up having to put more into this area than you want to. As I said, we use it ourselves for some stuff, but our needs are simple in that area. Its primary purpose is high-powered business database apps. Now on the third hand, we have a pure business app for Medical Practice Management and we are about to add the CRM to it so that the scheduling/billing database also serves the doctor's public website, doing things like showing schedules, listing active insurances and other nifty stuff like that. And of course the doc can enter new articles. We think its really cool to be able to integrate CRM with business this way. The only other bad news is that it is Linux only. It has been installed on Mac but nobody here can support you with that. In principle it can run on Windows because Apache, PHP and Postgres run on windows, but again, you'd become the guy I send other people to once you get it going :) Here are three CRM sites running it. They are my company site, the project site itself, and a site for a rental home: www.secdat.com www.andromeda-project.org www.manisteeforestretreat.com The middle one is the actual project, its got some docs, some tutorials, and a link to the sourceforge download.
On Mar 8, 2007, at 6:26 PM, Brent Wood wrote: > Bradley Kieser wrote: >> I hope that someone has cracked this one because I have run into a >> brick wall the entire week and after 3 all-nighters with bad >> installations, I would appreciate hearing from others! >> >> I am looking for a decent OpenSource CRM system that will run with >> Postgres. SugarCRM seems to be the most popular but it's MySQL- >> centric and its opensource parts are very restricted. > > Not a recommendation, coz I haven't actually used it, but you might > try Drupal, if you haven't already. I've seen Drupal work OK, & it > claims to support Postgres. It's not a CRM, though. Last time I looked, about a year ago, I came to the same conclusion as the OP. There are at least some excellent commercial CRMs that support postgresql, so there's no reason why the open source ones shouldn't, other than the whole open-source / PHP / MySQL hack mindset. That and the whole mysql installed base issue. Cheers, Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/07 20:38, Kenneth Downs wrote: [snip] > Management and we are about to add the CRM to it so that the > scheduling/billing database also serves the doctor's public website, Is that wise? One bug and a cracker is poking around some very private stuff!! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF8N6/S9HxQb37XmcRAsgfAKCq5hSw1XpU+piaL2RBoihoPTMfZwCdG5D3 YndimzGriPXUM49P9b596og= =wU1C -----END PGP SIGNATURE-----
On Fri, 2007-03-09 at 01:22 +0000, Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a brick > wall the entire week and after 3 all-nighters with bad installations, I > would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. > > vTiger is also mySQL-centric. > > I thought that I had a corker of a system with "centricCRM" but when it > came to actually installing it, I am 48 hours down and hacking through > screen after screen of installation errors. Basically, it relies way too > much on ant and Java tools. Nothing against Java but my experience with > ant used for installing PG schemas is a dismal track record of error and > frustration. centric CRM is no exception. Frankly, it just doesn't work > and after trying to hack out the ant into a PG script I have decided to > give it up as a bad job. > > XRMS promises to run on PG but... it doesn't. The core system is fine, > but useless without the plugins. The Plugins are mySQL-specific again, I > spent several all-nighters previously hacking through installation > screens attempting to convert mysql to PG, making software patches... > you get the picture. > > XLSuite looks very promising. Awesome interface, looks great... only > it's just not ready yet. It is a year away from being at full PG > production level. > > Compiere doesn't support PG. > > OpenTAPS the demo won't even work. And it's US-centric whereas we are in > the UK. A pity that it's so very much tied to the US as it could be very > good. > > I have tried numerous other CRMs but all the same - either don't run on > PG, claim to but in reality don't or are simply pre-Alpha and not ready > for production use. > > So if anyone has actually cracked this, please let me know! I really > need a good CRM. > > It has to be OpenSource, not just out of principle, but we need to > integrate it into an existing business with established inhouse software > so we need to be able to customise the code. ---- my experience with CRM stuff is that the general CRM application never does what you want and you are going to have to hack it no matter what. If you are comfortable with going PHP, you just download sugarcrm or vtiger or whatever comes closest to your vision of your needs and hack away from there. Myself, I am very much enthralled with Ruby on Rails and see it as an amazingly rapid development system and have been writing everything from scratch for our non-profit. Craig
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Mario Guenterberg
Date:
On Fri, Mar 09, 2007 at 01:22:22AM +0000, Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a brick > wall the entire week and after 3 all-nighters with bad installations, I > would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. > Hi... lxOffice runs with PostgreSQL. http://www.lx-office.org regards Mario -- ----------------------------------------------------- | havelsoft.com - Ihr Service Partner für Open Source | | Tel: 033876-21 966 | | Notruf: 0173-277 33 60 | | http://www.havelsoft.com | | | | Inhaber: Mario Günterberg | | Mützlitzer Strasse 19 | | 14715 Märkisch Luch | -----------------------------------------------------
Attachment
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
John Sidney-Woollett
Date:
centric crm works with postgres John Mario Guenterberg wrote: > On Fri, Mar 09, 2007 at 01:22:22AM +0000, Bradley Kieser wrote: >> I hope that someone has cracked this one because I have run into a brick >> wall the entire week and after 3 all-nighters with bad installations, I >> would appreciate hearing from others! >> >> I am looking for a decent OpenSource CRM system that will run with >> Postgres. SugarCRM seems to be the most popular but it's MySQL-centric >> and its opensource parts are very restricted. >> > Hi... > > lxOffice runs with PostgreSQL. > > http://www.lx-office.org > > regards > Mario >
Ron Johnson wrote:
We use the "Spartan" security model rather than perimeter defense, which gives us the confidence to do things that others may not.
The general outline is as follows.
First, security is defined directly in terms of tables, it is not arbitrated by code. The "public" group has SELECT access to the articles table and the schedules tables, that's it. If a person figures out how our links work and tries to access the "claims" table it will simply come up blank (and we get an email). The "staff" group has read/write access to scheduling, and so forth.
Second, the security assignments to tables are generated by a builder, which revokes and grants all priveleges to all groups on all tables. This is to prevent the possibility of error or omission if a person were to implement it table-by-table.
Third, as you probably have guessed, we do not connect to the database as a super-user and then arbitrate in code. Regular staff connect with real database accounts and their security in the database is limited to those accounts. Bugs in code that try to provide unauthorized information will return server errors. A person with no account, such as the public user, has the lowest security priveleges, as mentioned above.
Finally, our URL parameter scheme is really very simple and easy to figure out, we are not hiding it. Anybody trying to get something they can't would not take long to work it out (especially as the underlying tools are GPL), they would simply find it did them no good.
It is good to be very concerned about security, especially HIPPA, where there are legal ramifications. It is also very good to be able to provide convenience and security in one package.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/07 20:38, Kenneth Downs wrote: [snip]Management and we are about to add the CRM to it so that the scheduling/billing database also serves the doctor's public website,Is that wise? One bug and a cracker is poking around some very private stuff!!
We use the "Spartan" security model rather than perimeter defense, which gives us the confidence to do things that others may not.
The general outline is as follows.
First, security is defined directly in terms of tables, it is not arbitrated by code. The "public" group has SELECT access to the articles table and the schedules tables, that's it. If a person figures out how our links work and tries to access the "claims" table it will simply come up blank (and we get an email). The "staff" group has read/write access to scheduling, and so forth.
Second, the security assignments to tables are generated by a builder, which revokes and grants all priveleges to all groups on all tables. This is to prevent the possibility of error or omission if a person were to implement it table-by-table.
Third, as you probably have guessed, we do not connect to the database as a super-user and then arbitrate in code. Regular staff connect with real database accounts and their security in the database is limited to those accounts. Bugs in code that try to provide unauthorized information will return server errors. A person with no account, such as the public user, has the lowest security priveleges, as mentioned above.
Finally, our URL parameter scheme is really very simple and easy to figure out, we are not hiding it. Anybody trying to get something they can't would not take long to work it out (especially as the underlying tools are GPL), they would simply find it did them no good.
It is good to be very concerned about security, especially HIPPA, where there are legal ramifications. It is also very good to be able to provide convenience and security in one package.
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Walter Vaughan
Date:
Bradley Kieser wrote: > I am looking for a decent OpenSource CRM system that will run with > Postgres. > OpenTAPS the demo won't even work. And it's US-centric whereas we are in > the UK. A pity that it's so very much tied to the US as it could be very > good. What actually didn't work with OpenTaps? "OpenTaps" is additional modules that work with the Apache Open For Business project core product. What functions that SugarCRM supply that you need in OpenTaps? We are funding ($$,$$$ USD) a lot of changes right now in OpenTaps and OFBiz, and perhaps you could let me know where the feature gap is so that I don't end up with a "I can't believe we forgot about that". -- Walter
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote: > First, security is defined directly in terms of tables, it is not > arbitrated by code. The "public" group has SELECT access to the > articles table and the schedules tables, that's it. If a person figures > out how our links work and tries to access the "claims" table it will > simply come up blank (and we get an email). How ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Karsten Hilbert wrote:
If a user has not logged in, that is, if they are an anonymous visitor, the web framework will connect to the database as the default "public" user. Our system is deny-by-default, so this user cannot actually read from any table unless specifically granted permission. In the case being discussed, the public user is given SELECT permission on some columns of the insurance carriers table, and on the schedules table.
The column-level security is important, as you don't want anybody seeing the provider id!
If the user figures out our URL scheme, they might try something like "?gp_page=patients" and say "Wow I'm clever I'm going to look at the patients table", except that the public user has no privilege on the table. The db server will throw a permission denied error.
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:First, security is defined directly in terms of tables, it is not arbitrated by code. The "public" group has SELECT access to the articles table and the schedules tables, that's it. If a person figures out how our links work and tries to access the "claims" table it will simply come up blank (and we get an email).How ? Karsten
If a user has not logged in, that is, if they are an anonymous visitor, the web framework will connect to the database as the default "public" user. Our system is deny-by-default, so this user cannot actually read from any table unless specifically granted permission. In the case being discussed, the public user is given SELECT permission on some columns of the insurance carriers table, and on the schedules table.
The column-level security is important, as you don't want anybody seeing the provider id!
If the user figures out our URL scheme, they might try something like "?gp_page=patients" and say "Wow I'm clever I'm going to look at the patients table", except that the public user has no privilege on the table. The db server will throw a permission denied error.
>>> First, security is defined directly in terms of tables, it is not >>> arbitrated by code. The "public" group has SELECT access to the >>> articles table and the schedules tables, that's it. If a person >>> figures out how our links work and tries to access the "claims" table >>> it will simply come up blank (and we get an email). > If a user has not logged in, that is, if they are an anonymous visitor, > the web framework will connect to the database as the default "public" > user. Our system is deny-by-default, so this user cannot actually read > from any table unless specifically granted permission. In the case > being discussed, the public user is given SELECT permission on some > columns of the insurance carriers table, and on the schedules table. Huh. Does that imply that the web framework still holds a number of different DB credentials? Or does each user need to supply their specific DB credentials as their authentication so the web framework is merely a proxy to the DB? (Having recently discovered a major security oversight in one of my employer's webapps, my mind's hot on this kind of thing.) Kevin
In response to Kevin Hunter <hunteke@earlham.edu>: > >>> First, security is defined directly in terms of tables, it is not > >>> arbitrated by code. The "public" group has SELECT access to the > >>> articles table and the schedules tables, that's it. If a person > >>> figures out how our links work and tries to access the "claims" table > >>> it will simply come up blank (and we get an email). > > > If a user has not logged in, that is, if they are an anonymous visitor, > > the web framework will connect to the database as the default "public" > > user. Our system is deny-by-default, so this user cannot actually read > > from any table unless specifically granted permission. In the case > > being discussed, the public user is given SELECT permission on some > > columns of the insurance carriers table, and on the schedules table. > > Huh. Does that imply that the web framework still holds a number of > different DB credentials? Or does each user need to supply their > specific DB credentials as their authentication so the web framework is > merely a proxy to the DB? > > (Having recently discovered a major security oversight in one of my > employer's webapps, my mind's hot on this kind of thing.) What's hot in my mind is "how do you securely maintain the database connection information between page loads?" -- Bill Moran http://www.potentialtech.com
On Fri, Mar 09, 2007 at 11:02:45AM -0500, Kenneth Downs wrote: > >>First, security is defined directly in terms of tables, it is not > >>arbitrated by code. The "public" group has SELECT access to the > >>articles table and the schedules tables, that's it. If a person figures > >>out how our links work and tries to access the "claims" table it will > >>simply come up blank (and we get an email). > > If a user has not logged in, that is, if they are an anonymous visitor, > the web framework will connect to the database as the default "public" > user. Our system is deny-by-default, so this user cannot actually read > >from any table unless specifically granted permission. In the case > being discussed, the public user is given SELECT permission on some > columns of the insurance carriers table, and on the schedules table. > > The column-level security is important, as you don't want anybody seeing > the provider id! > > If the user figures out our URL scheme, they might try something like > "?gp_page=patients" and say "Wow I'm clever I'm going to look at the > patients table", except that the public user has no privilege on the > table. The db server will throw a permission denied error. My interest was more towards the "we get an email" part. What level do you send that from ? A trigger ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/07 10:02, Kenneth Downs wrote: > Karsten Hilbert wrote: >> On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote: >> >> >>> First, security is defined directly in terms of tables, it is not >>> arbitrated by code. The "public" group has SELECT access to the >>> articles table and the schedules tables, that's it. If a person >>> figures out how our links work and tries to access the "claims" table >>> it will simply come up blank (and we get an email). >>> >> How ? >> >> Karsten >> > > > If a user has not logged in, that is, if they are an anonymous visitor, > the web framework will connect to the database as the default "public" > user. Our system is deny-by-default, so this user cannot actually read > from any table unless specifically granted permission. In the case > being discussed, the public user is given SELECT permission on some > columns of the insurance carriers table, and on the schedules table. > > The column-level security is important, as you don't want anybody seeing > the provider id! > > If the user figures out our URL scheme, they might try something like > "?gp_page=patients" and say "Wow I'm clever I'm going to look at the > patients table", except that the public user has no privilege on the > table. The db server will throw a permission denied error. What about an SQL injection bug that allows for increased privileges? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF8ZHlS9HxQb37XmcRAjTMAKDSBDYYmTt9/ivGtl59YtITz5Lb4ACffLzQ MlCCcfGd5sS3aNhtgDrd+rA= =cwTh -----END PGP SIGNATURE-----
Karsten Hilbert wrote:
The web framework does that. The web framework decodes the HTTP request and executes any SQL it thinks the user wants. If there is a permissions error then it sends an email to the administrator.
The underlying idea is that the GET/POST parameters are pretty standard and easy to decode and convert into SQL commands. For instance, by default we assume a page = a table, and lacking any code that overrides that assumption, a request for a page becomes a search request in the table of the same name. This is the first thing a cracker would depend upon if he were trying to pry.
If the user figures out our URL scheme, they might try something like "?gp_page=patients" and say "Wow I'm clever I'm going to look at the patients table", except that the public user has no privilege on the table. The db server will throw a permission denied error.My interest was more towards the "we get an email" part. What level do you send that from ? A trigger ?
The web framework does that. The web framework decodes the HTTP request and executes any SQL it thinks the user wants. If there is a permissions error then it sends an email to the administrator.
The underlying idea is that the GET/POST parameters are pretty standard and easy to decode and convert into SQL commands. For instance, by default we assume a page = a table, and lacking any code that overrides that assumption, a request for a page becomes a search request in the table of the same name. This is the first thing a cracker would depend upon if he were trying to pry.
Ron Johnson wrote:
Um, web programming 101 is that you escape quotes on user-supplied inputs. That ends SQL injection.
After that, as stated above, anything the user attempts is executed at his privilege level. For an anonymous user, that's the lowest.
The biggest security limitation we have is actually a weakness in Postgres - the inability to restrict the abilities of a user with CREATUSER rights, they can make somebody who can do anything. For higher security this requires no ability for public registration of accounts. This would be solved if we could restrict a CREATUSER user to only GRANTing to roles they themselves are in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/07 10:02, Kenneth Downs wrote:Karsten Hilbert wrote:On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:First, security is defined directly in terms of tables, it is not arbitrated by code. The "public" group has SELECT access to the articles table and the schedules tables, that's it. If a person figures out how our links work and tries to access the "claims" table it will simply come up blank (and we get an email).How ? KarstenIf a user has not logged in, that is, if they are an anonymous visitor, the web framework will connect to the database as the default "public" user. Our system is deny-by-default, so this user cannot actually read from any table unless specifically granted permission. In the case being discussed, the public user is given SELECT permission on some columns of the insurance carriers table, and on the schedules table. The column-level security is important, as you don't want anybody seeing the provider id! If the user figures out our URL scheme, they might try something like "?gp_page=patients" and say "Wow I'm clever I'm going to look at the patients table", except that the public user has no privilege on the table. The db server will throw a permission denied error.What about an SQL injection bug that allows for increased privileges?
Um, web programming 101 is that you escape quotes on user-supplied inputs. That ends SQL injection.
After that, as stated above, anything the user attempts is executed at his privilege level. For an anonymous user, that's the lowest.
The biggest security limitation we have is actually a weakness in Postgres - the inability to restrict the abilities of a user with CREATUSER rights, they can make somebody who can do anything. For higher security this requires no ability for public registration of accounts. This would be solved if we could restrict a CREATUSER user to only GRANTing to roles they themselves are in.
Karsten- You would need some manner of DML operation to take place (in this way the DB trigger could sense the change in DB stateto activate e-mail) Otherwise you could do so at your Webapp login Does this answer your question? Tak Martin-- --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressedand may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you arenot the intended recipient, you are notified that any dissemination, distribution or copying of this communication isstrictly prohibited. --------------------------------------------------------------------------- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiquéet peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document,nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. ----- Original Message ----- From: "Karsten Hilbert" <Karsten.Hilbert@gmx.net> To: <pgsql-general@postgresql.org> Sent: Friday, March 09, 2007 11:45 AM Subject: Re: HIPPA (was Re: [GENERAL] Anyone know ...) > On Fri, Mar 09, 2007 at 11:02:45AM -0500, Kenneth Downs wrote: > >> >>First, security is defined directly in terms of tables, it is not >> >>arbitrated by code. The "public" group has SELECT access to the >> >>articles table and the schedules tables, that's it. If a person figures >> >>out how our links work and tries to access the "claims" table it will >> >>simply come up blank (and we get an email). >> >> If a user has not logged in, that is, if they are an anonymous visitor, >> the web framework will connect to the database as the default "public" >> user. Our system is deny-by-default, so this user cannot actually read >> >from any table unless specifically granted permission. In the case >> being discussed, the public user is given SELECT permission on some >> columns of the insurance carriers table, and on the schedules table. >> >> The column-level security is important, as you don't want anybody seeing >> the provider id! >> >> If the user figures out our URL scheme, they might try something like >> "?gp_page=patients" and say "Wow I'm clever I'm going to look at the >> patients table", except that the public user has no privilege on the >> table. The db server will throw a permission denied error. > > My interest was more towards the "we get an email" part. > What level do you send that from ? A trigger ? > > Karsten > -- > GPG key ID E4071346 @ wwwkeys.pgp.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
Kevin Hunter wrote: > >> If a user has not logged in, that is, if they are an anonymous >> visitor, the web framework will connect to the database as the >> default "public" user. Our system is deny-by-default, so this user >> cannot actually read from any table unless specifically granted >> permission. In the case being discussed, the public user is given >> SELECT permission on some columns of the insurance carriers table, >> and on the schedules table. > > Huh. Does that imply that the web framework still holds a number of > different DB credentials? Or does each user need to supply their > specific DB credentials as their authentication so the web framework > is merely a proxy to the DB? Yes, exactly, the web framework can be thought of as a proxy, it is connecting to the DB using credentials provided by the user. Which, I will take pains to point out, is far far superior to having it connect as a super-user and then trusting that the code is bug-free. Ouch, I don't even want to think about that one. But anyway, once we arrive at this point you arrive at the standard questions surrounding session security and the possible use of certificates. The system is now as secure as your user's password habits and your server's general security.
Bill Moran wrote:
I suppose we could ask JP Morgan Chase bank what they do. As I mentioned to Kevin, sooner or later the security implementation comes down to sessions, the user's protection of their password, whether to use certificates, whether to use dongles, etc.
If a user has not logged in, that is, if they are an anonymous visitor, the web framework will connect to the database as the default "public" user. Our system is deny-by-default, so this user cannot actually read from any table unless specifically granted permission. In the case being discussed, the public user is given SELECT permission on some columns of the insurance carriers table, and on the schedules table.Huh. Does that imply that the web framework still holds a number of different DB credentials? Or does each user need to supply their specific DB credentials as their authentication so the web framework is merely a proxy to the DB? (Having recently discovered a major security oversight in one of my employer's webapps, my mind's hot on this kind of thing.)What's hot in my mind is "how do you securely maintain the database connection information between page loads?"
I suppose we could ask JP Morgan Chase bank what they do. As I mentioned to Kevin, sooner or later the security implementation comes down to sessions, the user's protection of their password, whether to use certificates, whether to use dongles, etc.
>> What about an SQL injection bug that allows for increased privileges? > > Um, web programming 101 is that you escape quotes on user-supplied > inputs. That ends SQL injection. Pardon my naivete (I'm fairly new to web/DB programming) . . . is this the current standard method of protection from SQL injection? How does it compare to SQL preparation with bound variables? Kevin
Kevin Hunter wrote: >>> What about an SQL injection bug that allows for increased privileges? >> >> Um, web programming 101 is that you escape quotes on user-supplied >> inputs. That ends SQL injection. > > Pardon my naivete (I'm fairly new to web/DB programming) . . . is this > the current standard method of protection from SQL injection? How > does it compare to SQL preparation with bound variables? When you use SQL Prepared statements it is normal for the db driver to escape out the variables for you. Well at least it is in PHP, I can't say for other systems. > > Kevin
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Sven Willenberger
Date:
On Fri, 2007-03-09 at 01:22 +0000, Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a brick > wall the entire week and after 3 all-nighters with bad installations, I > would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. > > vTiger is also mySQL-centric. > > I thought that I had a corker of a system with "centricCRM" but when it > came to actually installing it, I am 48 hours down and hacking through > screen after screen of installation errors. Basically, it relies way too > much on ant and Java tools. Nothing against Java but my experience with > ant used for installing PG schemas is a dismal track record of error and > frustration. centric CRM is no exception. Frankly, it just doesn't work > and after trying to hack out the ant into a PG script I have decided to > give it up as a bad job. > > XRMS promises to run on PG but... it doesn't. The core system is fine, > but useless without the plugins. The Plugins are mySQL-specific again, I > spent several all-nighters previously hacking through installation > screens attempting to convert mysql to PG, making software patches... > you get the picture. > > XLSuite looks very promising. Awesome interface, looks great... only > it's just not ready yet. It is a year away from being at full PG > production level. > > Compiere doesn't support PG. > > OpenTAPS the demo won't even work. And it's US-centric whereas we are in > the UK. A pity that it's so very much tied to the US as it could be very > good. > > I have tried numerous other CRMs but all the same - either don't run on > PG, claim to but in reality don't or are simply pre-Alpha and not ready > for production use. > > So if anyone has actually cracked this, please let me know! I really > need a good CRM. > > It has to be OpenSource, not just out of principle, but we need to > integrate it into an existing business with established inhouse software > so we need to be able to customise the code. > Stumbled across this one: http://www.hipergate.org/ which appears to be crm and groupware that works with postgresql (requires version 8.x so it appears to be relatively up to date development-wise). It is java based apparently so it may not be so palatable for you.
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
"Brandon Aiken"
Date:
Why is running on PG so important? Why not look for the best CRM
application for your user's needs?
--
Brandon Aiken
CS/IT Systems Engineer
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Bradley Kieser
Sent: Thursday, March 08, 2007 8:22 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Anyone know a good opensource CRM that actually
installs with Posgtres?
I hope that someone has cracked this one because I have run into a brick
wall the entire week and after 3 all-nighters with bad installations, I
would appreciate hearing from others!
I am looking for a decent OpenSource CRM system that will run with
Postgres. SugarCRM seems to be the most popular but it's MySQL-centric
and its opensource parts are very restricted.
vTiger is also mySQL-centric.
I thought that I had a corker of a system with "centricCRM" but when it
came to actually installing it, I am 48 hours down and hacking through
screen after screen of installation errors. Basically, it relies way too
much on ant and Java tools. Nothing against Java but my experience with
ant used for installing PG schemas is a dismal track record of error and
frustration. centric CRM is no exception. Frankly, it just doesn't work
and after trying to hack out the ant into a PG script I have decided to
give it up as a bad job.
XRMS promises to run on PG but... it doesn't. The core system is fine,
but useless without the plugins. The Plugins are mySQL-specific again, I
spent several all-nighters previously hacking through installation
screens attempting to convert mysql to PG, making software patches...
you get the picture.
XLSuite looks very promising. Awesome interface, looks great... only
it's just not ready yet. It is a year away from being at full PG
production level.
Compiere doesn't support PG.
OpenTAPS the demo won't even work. And it's US-centric whereas we are in
the UK. A pity that it's so very much tied to the US as it could be very
good.
I have tried numerous other CRMs but all the same - either don't run on
PG, claim to but in reality don't or are simply pre-Alpha and not ready
for production use.
So if anyone has actually cracked this, please let me know! I really
need a good CRM.
It has to be OpenSource, not just out of principle, but we need to
integrate it into an existing business with established inhouse software
so we need to be able to customise the code.
Thanks,
Brad
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--------------------------------------------------------------------
** LEGAL DISCLAIMER **
Statements made in this e-mail may or may not reflect the views and
opinions of Wineman Technology, Inc. or its employees.
This e-mail message and any attachments may contain legally privileged,
confidential or proprietary information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this e-mail
message is strictly prohibited. If you have received this message in
error, please immediately notify the sender and delete this e-mail
message from your computer.
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
"Merlin Moncure"
Date:
On 3/9/07, Brandon Aiken <BAiken@winemantech.com> wrote: > Why is running on PG so important? Why not look for the best CRM > application for your user's needs? probably because he wants to interface his own systems on it that are already running on postgresql. merlin
On Mar 9, 2007, at 11:35 AM, Brandon Aiken wrote: > Why is running on PG so important? Why not look for the best CRM > application for your user's needs? There can be many reasons - mostly related to the fact that the business needs are at least as important, if not more so, than the user needs. Running a second corporate database doubles DBA and sysadmin overhead (let alone the amount of learning needed to support it effectively, including maintenance, tuning, backup, disaster recovery, security, updates...). Also, I wouldn't want any business-critical CRM data on a database I didn't trust to not lose or corrupt it. I'm still undecided on whether I trust databases beginning with "M" that much, and I'm certainly not as confident in them as I am in PG. I quite like SugarCRM, but I'm not ready to rely on it, mostly for this reason. Because I may want to modify it to meet my needs (which also answers the "why open source rather than proprietary?" question), which requires an even more intimate knowledge of the quirks of the database than basic maintenance. Cheers, Steve
On Fri, Mar 09, 2007 at 12:22:19PM -0500, Kenneth Downs wrote: > >My interest was more towards the "we get an email" part. > >What level do you send that from ? A trigger ? > > > The web framework does that. I see. IOW if a violation happens below the web layer the e-mail doesn't get send. I thought you had maybe written a trigger to do it in, say, pl/Perl or so. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Kenneth Downs <ken@secdat.com> writes:
> The biggest security limitation we have is actually a weakness in
> Postgres - the inability to restrict the abilities of a user with
> CREATUSER rights, they can make somebody who can do anything. For
> higher security this requires no ability for public registration of
> accounts. This would be solved if we could restrict a CREATUSER user to
> only GRANTing to roles they themselves are in.
I thought about this for awhile, but I think you are missing the reason
why it's designed the way it is. The point of CREATEROLE privilege is
to be a slightly safer form of superuser: that is, to allow the DBA to
do all his day-to-day management of user accounts without being a real
superuser who can corrupt the database arbitrarily badly. If we
restricted CREATEROLE as you suggest, then either DBAs would have to
make their CREATEROLE account a member of every role they manage, or
they'd have to run as real superusers. Either choice represents a
significant increase in the capabilities of the CREATEROLE account and
thus more chance for mistakes. So while a miscreant with CREATEROLE
can certainly avail himself of any database privilege short of
superuserness, in the intended use of the feature it is actually
possible for DBAs to operate with *fewer* privileges than they would
need to get useful work done if we adopted your suggestion.
regards, tom lane
Hello, Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a brick > wall the entire week and after 3 all-nighters with bad installations, I > would appreciate hearing from others! > [...] > Compiere doesn't support PG. You could checkout Adempiere wich is a fork of Compiere: <http://www.adempiere.com/> They claim to support PG and they are actively improving on that: <http://www.adempiere.com/wiki/index.php/Release_315> Download location: <http://sourceforge.net/project/showfiles.php?group_id=176962&package_id=207834> > I have tried numerous other CRMs but all the same - either don't run on > PG, claim to but in reality don't or are simply pre-Alpha and not ready > for production use. On the surface Adempiere seems to meet your requirements but I never used it so I can't tell if its another dead end. -- Luis Neves
Tom Lane wrote:
Tom, it sounds like you've thought this through, and I can't disagree with the reality of what DBA's are doing, but does it have to be one or the other?
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create roles and only grant to the roles he himself is a member of.
This suggestion I think would be in line with your own reasoning. Just as CREATEROLE is a lesser SUPERUSER, so CREATEROLE_LIMITED is the next logical extension, a lesser CREATEROLE.
At any rate, I hope I can convince somebody, cuz ole Ken don't code in C no more :)
Kenneth Downs <ken@secdat.com> writes:The biggest security limitation we have is actually a weakness in Postgres - the inability to restrict the abilities of a user with CREATUSER rights, they can make somebody who can do anything. For higher security this requires no ability for public registration of accounts. This would be solved if we could restrict a CREATUSER user to only GRANTing to roles they themselves are in.I thought about this for awhile, but I think you are missing the reason why it's designed the way it is. The point of CREATEROLE privilege is to be a slightly safer form of superuser: that is, to allow the DBA to do all his day-to-day management of user accounts without being a real superuser who can corrupt the database arbitrarily badly. If we restricted CREATEROLE as you suggest, then either DBAs would have to make their CREATEROLE account a member of every role they manage, or they'd have to run as real superusers. Either choice represents a significant increase in the capabilities of the CREATEROLE account and thus more chance for mistakes. So while a miscreant with CREATEROLE can certainly avail himself of any database privilege short of superuserness, in the intended use of the feature it is actually possible for DBAs to operate with *fewer* privileges than they would need to get useful work done if we adopted your suggestion.
Tom, it sounds like you've thought this through, and I can't disagree with the reality of what DBA's are doing, but does it have to be one or the other?
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create roles and only grant to the roles he himself is a member of.
This suggestion I think would be in line with your own reasoning. Just as CREATEROLE is a lesser SUPERUSER, so CREATEROLE_LIMITED is the next logical extension, a lesser CREATEROLE.
At any rate, I hope I can convince somebody, cuz ole Ken don't code in C no more :)
Re: Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Rich Shepard
Date:
On Fri, 9 Mar 2007, lneves wrote: >> I hope that someone has cracked this one because I have run into a brick >> wall the entire week and after 3 all-nighters with bad installations, I >> would appreciate hearing from others! > You could checkout Adempiere wich is a fork of Compiere: > <http://www.adempiere.com/> I'll look at this, too. Last year I spent a lot of time seeking a CRM (for sales, not web site content) that worked with postgres and ended up frustrated. XRMS is supposed to (it's written in PHP and uses the ADODB interface layer, but since the company officially supports only mysql, they have too much mysql-specific code in there.) Then there's ZohoCRM, which _does_ use postgres. But, it will work only with the 8.0.x version they provide. That means we'd have to have both our current versions and a second full installation of an older version to run their software. I wrote to Zoho about this. Did not get a response. Weeks later I received an e-mail from someone there asking about my experiences with it. My response was that I could not install it because no one there told me how to modify it to use my existing postgres installation. No response to that, either. I suppose I could look at the code, but I have to spend my time on my own business and not figure out how to make someone else's project work here. Why they welded the application to a specific postgres version that must be installed from their web site I've no idea. Doesn't make any sense to me. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
Kenneth Downs <ken@secdat.com> writes:
> Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
> roles and only grant to the roles he himself is a member of.
You can make that out of spare parts today, by granting non-superusers
execute rights on functions that create users.
regression=# create or replace function makeuser(text) returns void as $$
begin
execute 'create role ' || quote_ident($1) || ' login';
end$$ language plpgsql security definer;
CREATE FUNCTION
regression=# revoke all on function makeuser(text) from public;
REVOKE
regression=# create user joe;
CREATE ROLE
regression=# grant execute on function makeuser(text) to joe;
GRANT
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> create user foo;
ERROR: permission denied to create role
regression=> select makeuser('foo');
makeuser
----------
(1 row)
regression=> \c - foo
You are now connected to database "regression" as user "foo".
regression=>
regards, tom lane
Awesome! That never occurred to me. This is really cool.
Tom Lane wrote:
Tom Lane wrote:
Kenneth Downs <ken@secdat.com> writes:Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create roles and only grant to the roles he himself is a member of.You can make that out of spare parts today, by granting non-superusers execute rights on functions that create users. regression=# create or replace function makeuser(text) returns void as $$ begin execute 'create role ' || quote_ident($1) || ' login'; end$$ language plpgsql security definer; CREATE FUNCTION regression=# revoke all on function makeuser(text) from public; REVOKE regression=# create user joe; CREATE ROLE regression=# grant execute on function makeuser(text) to joe; GRANT regression=# \c - joe You are now connected to database "regression" as user "joe". regression=> create user foo; ERROR: permission denied to create role regression=> select makeuser('foo');makeuser ---------- (1 row) regression=> \c - foo You are now connected to database "regression" as user "foo". regression=> regards, tom lane
That's basically what I've done with my past questions on the ROLE system in place. Since roles are global, I wanted it fine grained to the DB level so I had to append DB_ in front of each role name and by using current_database() inside my functions, I could hide that from the exterior.
Now I have a web administration panel that can let me administer users and groups. Functions are synced with app permissions and given to groups only. Then users are assigned to groups to give them their app permissions + db function permissions. I had to create a couple extra tables to do the sync between app permissions (view page X, do action Y) and the functions needed for each of these app permission combos.
Users of my products will now be able to control all the users via that panel, it also removes any superuser credentials on the app level as now the DB users are used for the web app login too.
I'm very pleased to have learned this new database and its incorporation in my apps and future apps.
David
Now I have a web administration panel that can let me administer users and groups. Functions are synced with app permissions and given to groups only. Then users are assigned to groups to give them their app permissions + db function permissions. I had to create a couple extra tables to do the sync between app permissions (view page X, do action Y) and the functions needed for each of these app permission combos.
Users of my products will now be able to control all the users via that panel, it also removes any superuser credentials on the app level as now the DB users are used for the web app login too.
I'm very pleased to have learned this new database and its incorporation in my apps and future apps.
David
On 3/10/07, Kenneth Downs <ken@secdat.com> wrote:
Awesome! That never occurred to me. This is really cool.
Tom Lane wrote:Kenneth Downs <ken@secdat.com> writes:
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
roles and only grant to the roles he himself is a member of.
You can make that out of spare parts today, by granting non-superusers
execute rights on functions that create users.
regression=# create or replace function makeuser(text) returns void as $$
begin
execute 'create role ' || quote_ident($1) || ' login';
end$$ language plpgsql security definer;
CREATE FUNCTION
regression=# revoke all on function makeuser(text) from public;
REVOKE
regression=# create user joe;
CREATE ROLE
regression=# grant execute on function makeuser(text) to joe;
GRANT
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> create user foo;
ERROR: permission denied to create role
regression=> select makeuser('foo');
makeuser
----------
(1 row)
regression=> \c - foo
You are now connected to database "regression" as user "foo".
regression=>
regards, tom lane
David Legault escribió: > That's basically what I've done with my past questions on the ROLE system in > place. Since roles are global, I wanted it fine grained to the DB level so I > had to append DB_ in front of each role name and by using current_database() > inside my functions, I could hide that from the exterior. Hmm, there used to be a facility to restrict users to specific databases, enabled by db_user_namespace (not by default). It seems to still work on 8.2 ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
there is also the 'samegroup' facility in pg_hba.conf. We create a group named after each database, and a person cannot get into a database unless they are in that group.
David Legault escribió:That's basically what I've done with my past questions on the ROLE system in place. Since roles are global, I wanted it fine grained to the DB level so I had to append DB_ in front of each role name and by using current_database() inside my functions, I could hide that from the exterior.Hmm, there used to be a facility to restrict users to specific databases, enabled by db_user_namespace (not by default). It seems to still work on 8.2 ...
there is also the 'samegroup' facility in pg_hba.conf. We create a group named after each database, and a person cannot get into a database unless they are in that group.
On 3/10/07, Kenneth Downs <ken@secdat.com> wrote:
I tried this, but couldn't achieve what I wanted with it, it's also marked as "temp stuff could change in the future".
Alvaro Herrera wrote:David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my functions, I could hide that from the exterior.
Hmm, there used to be a facility to restrict users to specific
databases, enabled by db_user_namespace (not by default).
I tried this, but couldn't achieve what I wanted with it, it's also marked as "temp stuff could change in the future".
It seems to still work on 8.2 ...
there is also the 'samegroup' facility in pg_hba.conf. We create a group named after each database, and a person cannot get into a database unless they are in that group.
I append the name of the DB on front of the roles and it works flawlessly, you can't have 2 DB with the same name in the cluster. It's also transparent to the application since the functions to interact with the roles + other tables use current_database() which gets the name of the DB to which the groups are assigned.
All databases are REVOKED from public as all functions. When a user is created he is granted connect on the database to which he belongs. So even if someone gets the credentials to db1_user and attempts to connect to db2 with it it will fail.
David
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
Bricklen Anderson
Date:
Bradley Kieser wrote: > I hope that someone has cracked this one because I have run into a brick > wall the entire week and after 3 all-nighters with bad installations, I > would appreciate hearing from others! > > I am looking for a decent OpenSource CRM system that will run with > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > and its opensource parts are very restricted. > <snip> > So if anyone has actually cracked this, please let me know! I really > need a good CRM. > > It has to be OpenSource, not just out of principle, but we need to > integrate it into an existing business with established inhouse software > so we need to be able to customise the code. > > Thanks, > > Brad A coworker of mine (Ryley Breiddal) did some coding and testing for the SugarCRM PostgreSQL port, in conjunction with Jason Felice. We have been running it for a few months with no major problems. http://eraserhead.net/sugarsuite-pgpatch/
On Mar 9, 3:35 pm, BAi...@winemantech.com ("Brandon Aiken") wrote:
> Why is running on PG so important? Why not look for the bestCRM
> application for your user's needs?
>
> --
> Brandon Aiken
> CS/IT Systems Engineer
>
>
>
> -----Original Message-----
> From: pgsql-general-ow...@postgresql.org
>
> [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Bradley Kieser
> Sent: Thursday, March 08, 2007 8:22 PM
> To: pgsql-gene...@postgresql.org
> Subject: [GENERAL] Anyone know a good opensourceCRMthat actually
> installs with Posgtres?
>
> I hope that someone has cracked this one because I have run into a brick
>
> wall the entire week and after 3 all-nighters with bad installations, I
> would appreciate hearing from others!
>
> I am looking for a decent OpenSourceCRMsystem that will run with
> Postgres. SugarCRM seems to be the most popular but it's MySQL-centric
> and its opensource parts are very restricted.
>
> vTiger is also mySQL-centric.
>
> I thought that I had a corker of a system with "centricCRM" but when it
> came to actually installing it, I am 48 hours down and hacking through
> screen after screen of installation errors. Basically, it relies way too
>
> much on ant and Java tools. Nothing against Java but my experience with
> ant used for installing PG schemas is a dismal track record of error and
>
> frustration. centricCRMis no exception. Frankly, it just doesn't work
> and after trying to hack out the ant into a PG script I have decided to
> give it up as a bad job.
>
> XRMS promises to run on PG but... it doesn't. The core system is fine,
> but useless without the plugins. The Plugins are mySQL-specific again, I
>
> spent several all-nighters previously hacking through installation
> screens attempting to convert mysql to PG, making software patches...
> you get the picture.
>
> XLSuite looks very promising. Awesome interface, looks great... only
> it's just not ready yet. It is a year away from being at full PG
> production level.
>
> Compiere doesn't support PG.
>
> OpenTAPS the demo won't even work. And it's US-centric whereas we are in
>
> the UK. A pity that it's so very much tied to the US as it could be very
>
> good.
>
> I have tried numerous other CRMs but all the same - either don't run on
> PG, claim to but in reality don't or are simply pre-Alpha and not ready
> for production use.
>
> So if anyone has actually cracked this, please let me know! I really
> need a goodCRM.
>
> It has to be OpenSource, not just out of principle, but we need to
> integrate it into an existing business with established inhouse software
>
> so we need to be able to customise the code.
>
> Thanks,
>
> Brad
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
> --------------------------------------------------------------------
> ** LEGAL DISCLAIMER **
> Statements made in this e-mail may or may not reflect the views and
> opinions of Wineman Technology, Inc. or its employees.
>
> This e-mail message and any attachments may contain legally privileged,
> confidential or proprietary information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of
> this message to the intended recipient(s), you are hereby notified
> that any dissemination, distribution or copying of this e-mail
> message is strictly prohibited. If you have received this message in
> error, please immediately notify the sender and delete this e-mail
> message from your computer.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majord...@postgresql.org so that your
> message can get through to the mailing list cleanly- Hide quoted text -
>
> - Show quoted text -
Take a look at QueWeb from Queplix. It is mostly for Service/support
and Customer Care, limited SFA, as Queplix does not focus on sales but
rather on post-sales processes. It has an enterprise and OSS versions
(GPL license). Enterprise is run by many Fortune-500. OSS version is
posted on code.google.com/hosting. Look it up there. It is J2EE based.
Enterprise version works with all major databases (and PG), however
the OSS version comes with installer for JBoss and MySQL only.
You mention Compier not running on PG. Did you look ad ADempiere (http://www.adempiere.com/)? Its a fork of Compiere whichclaims to run especially with PG (though I did not yet have the time to test it). Regards, Frank. On 4 May 2007 20:07:17 -0700 syaskin <syaskin@queplix.com> thought long, then sat down and wrote: > On Mar 9, 3:35 pm, BAi...@winemantech.com ("Brandon Aiken") wrote: > > Why is running on PG so important? Why not look for the bestCRM > > application for your user's needs? > > > > -- > > Brandon Aiken > > CS/IT Systems Engineer > > > > > > > > -----Original Message----- > > From: pgsql-general-ow...@postgresql.org > > > > [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Bradley Kieser > > Sent: Thursday, March 08, 2007 8:22 PM > > To: pgsql-gene...@postgresql.org > > Subject: [GENERAL] Anyone know a good opensourceCRMthat actually > > installs with Posgtres? > > > > I hope that someone has cracked this one because I have run into a brick > > > > wall the entire week and after 3 all-nighters with bad installations, I > > would appreciate hearing from others! > > > > I am looking for a decent OpenSourceCRMsystem that will run with > > Postgres. SugarCRM seems to be the most popular but it's MySQL-centric > > and its opensource parts are very restricted. > > > > vTiger is also mySQL-centric. > > > > I thought that I had a corker of a system with "centricCRM" but when it > > came to actually installing it, I am 48 hours down and hacking through > > screen after screen of installation errors. Basically, it relies way too > > > > much on ant and Java tools. Nothing against Java but my experience with > > ant used for installing PG schemas is a dismal track record of error and > > > > frustration. centricCRMis no exception. Frankly, it just doesn't work > > and after trying to hack out the ant into a PG script I have decided to > > give it up as a bad job. > > > > XRMS promises to run on PG but... it doesn't. The core system is fine, > > but useless without the plugins. The Plugins are mySQL-specific again, I > > > > spent several all-nighters previously hacking through installation > > screens attempting to convert mysql to PG, making software patches... > > you get the picture. > > > > XLSuite looks very promising. Awesome interface, looks great... only > > it's just not ready yet. It is a year away from being at full PG > > production level. > > > > Compiere doesn't support PG. > > > > OpenTAPS the demo won't even work. And it's US-centric whereas we are in > > > > the UK. A pity that it's so very much tied to the US as it could be very > > > > good. > > > > I have tried numerous other CRMs but all the same - either don't run on > > PG, claim to but in reality don't or are simply pre-Alpha and not ready > > for production use. > > > > So if anyone has actually cracked this, please let me know! I really > > need a goodCRM. > > > > It has to be OpenSource, not just out of principle, but we need to > > integrate it into an existing business with established inhouse software > > > > so we need to be able to customise the code. > > > > Thanks, > > > > Brad > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > > -------------------------------------------------------------------- > > ** LEGAL DISCLAIMER ** > > Statements made in this e-mail may or may not reflect the views and > > opinions of Wineman Technology, Inc. or its employees. > > > > This e-mail message and any attachments may contain legally privileged, > > confidential or proprietary information. If you are not the intended > > recipient(s), or the employee or agent responsible for delivery of > > this message to the intended recipient(s), you are hereby notified > > that any dissemination, distribution or copying of this e-mail > > message is strictly prohibited. If you have received this message in > > error, please immediately notify the sender and delete this e-mail > > message from your computer. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majord...@postgresql.org so that your > > message can get through to the mailing list cleanly- Hide quoted text - > > > > - Show quoted text - > > Take a look at QueWeb from Queplix. It is mostly for Service/support > and Customer Care, limited SFA, as Queplix does not focus on sales but > rather on post-sales processes. It has an enterprise and OSS versions > (GPL license). Enterprise is run by many Fortune-500. OSS version is > posted on code.google.com/hosting. Look it up there. It is J2EE based. > Enterprise version works with all major databases (and PG), however > the OSS version comes with installer for JBoss and MySQL only. > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Frank Finner Invenius - Lösungen mit Linux Köpfchenstraße 36 57072 Siegen Telefon: 0271 231 8606 Mail: frank.finner@invenius.de Telefax: 0271 231 8608 Web: http://www.invenius.de Key fingerprint = 90DF FF40 582E 6D6B BADF 6E6A A74E 67E4 E788 2651
Attachment
Re: Anyone know a good opensource CRM that actually installs with Posgtres?
From
"Richard P. Welty"
Date:
Frank Finner wrote: > You mention Compier not running on PG. Did you look ad ADempiere (http://www.adempiere.com/)? Its a fork of Compiere whichclaims to run especially with PG (though I did not yet have the time to test it). > i did a test install of Adempiere against PostgreSQL on a FC5 box a while back. the installation process is kind of a pain, the docs aren't real good, but eventually i did get a reasonably functional version of Adempiere working. It all pretty much seemed to be there. richard
Richard P. Welty escribió: > Frank Finner wrote: >> You mention Compier not running on PG. Did you look ad ADempiere >> (http://www.adempiere.com/)? Its a fork of Compiere which claims to >> run especially with PG (though I did not yet have the time to test it). >> > i did a test install of Adempiere against PostgreSQL on a FC5 box a > while back. > > the installation process is kind of a pain, the docs aren't real good, > but eventually i did get a reasonably functional version of Adempiere > working. It all pretty much seemed to be there. > > richard > > I second Frank on this: Adempiere is starting to be really PostgreSQL oriented (they started with Oracle). You can reach the Adempiere developers at #adempiere in irc.freenode.org. Maybe they don't mind a few questions.