Hi,
Suitecrm is initialized and picks up the config file as soon as we type the URL and hit enter to access the CRM.
Is there any way if I would like to do any processing (pass the parameter and change the config file value) in the suitecrm?
Sorry, can you explain this abit more.
If you need to change config settings then you can edit the file itself config.php
What parameters do you want to pass?
Thanks for your replyā¦
On the backend we have created multiple database/schema. Now on the SuiteCRM we would like to change the config file (DB connection parameters) on basis of the selection from the user (from the UI / screen). We are creating a UI where user will select the value from dropdown and on the basis of the selected user value (DB values which contains the DB to connect) the config files will be connected to the selected Database
Hope it clarifies
Yes, it does but that opens up a can of worms.
SuiteCRM uses BOTH database and file changes (vardefs etc) to construct layouts and field definitions. Even if you have two different database schemas (why?), you would need to ensure that if you swap one database out, that the correct vardefs/field definitions have also been swapped out on the instanceās level. Honestly, it would be easier having two separate instances with having a script to automate any studio changes/database changes between the two to which the user can select which instance they want to visit by URL.
But, if you really want to explore define a parameter to define database connection you need to consider that with EVERY request it has the parameter to which config you want to use. Iām not sure if you can do it at the index.php where you could set a new User preference defining the database identifier and that on every call to index.php you intercept, check that parameter exists and if does, then inject/replace references to which config you want to include. There will be alot of core changes I suspect (unless getting config is in a singlar place) which you need to ensure itās reference the selected dynamic config.
Hi,
I have created organization (organization_id = schema_id) and mapped user to the specific organization they belong to. For every organization I would like to connect to a different DB schema. How can I pass the organization id/schema id to connect to a specific schema from the login page?
Interesting. It doesnāt exist in the standard version. You might need to create you custom login page for that.
One option that might work is to set one of the sites as the default one and then create a logic hook that checks logins and you can include your logic there to do what ever you want:
Hi, I have created a custom login Page. Problem is that as soon as suitecrm is initialized it is connecting to the default database from config file.
Is there any other way around?
This approach youāre trying is a dead end. Youād need to be a very knowledgeable SuiteCRM expert to make it work. Youāre trying to go against the architecture of a very large and complex app, itās not worth the effort. Just learn how it is meant to work and adapt to that.
You can separate organizations (somewhat) by using Security Groups to show different records to each. But beyond that, it will prove extremely hard to achieve.
Thanks samus-aran
I have defined the parameter and passing in the URL for the first time it is getting correct and connected to the right DB, but as SuiteCRM generates the URL dynamically I am not able to pass the parameter to the other links. i.e if i click on contacts, accounts or other menu.
Is there any file/line of code where suitecrm generates these link?
Iām not sure how easy that would be to apply everywhere (hence my EVERYWHERE captials haha). Would perhaps defining the connecting db be better as a user preference? that it sticks with the user internally rather than a URL parameters. How you initialize that you could have a dropdown (as you said) upon login which defines that (Iām sure there is an after logic logic hook perhapsā¦) and would create a user preference (for both databases so the data integrity is intact? 
) After which you should be able to get the user preference anywhere in the application logic including the utils which will pull in the config details (based on your new user preferences.
Of course these are all ideas so it may or may not work.
Hi Aiebee
I second what pgr said -but for different reasons -
He wrote about the architectural brickwall.
My reason is one of preventing your company being sued by your clients for breaching data privacy laws - see below.
So far, from what youāve written itās not clear as to
- what is the drawback of hosting each client seperately
- what your specific needs are, beyond
- a) a seperate MYSQL database per tenant
- b) users want to seperate their own data into multiple seperate MySQL instances, which they choose when they login (that sounds confusing and error prone for users?)
DJ
Details - Regards protecting your clients data
Assuming that your clients must comply with data privacy laws that mean they are are legally obligated to keep secure and private the data of their own customers/contacts:
If you made clear to your clients the security/privacy reality - do your commercial bosses think that potential clients would still want to sign up, if your contract with them stated:
- ādear customer - your data will be in a system not designed for multi-tenancy: we have introduced new functionality, not proven anywhere else in the world, to get round that - this introduces a significant new risk not part of SuiteCRM, that any of several simple mistakes we might make would directly result in other users of our system (when they login using their own CRM logins) seeing not their data but your data ie the personal information of your contacts and customers held in your CRMā
1 Like
Hi DJuser,
Thanks for the message
How breaching data privacy is possible, if a user is connected to his own company database and not other database/schema. Please explain
To answer your points:
- what is the drawback of hosting each client seperately
Response aiebee - Maintenance & Upgrade drawbacks
- what your specific needs are, beyond
- a) a seperate MYSQL database per tenant
- b) users want to seperate their own data into multiple seperate MySQL instances, which they choose when they login (that sounds confusing and error prone for users?)
Response aiebee - Yes (point a) ) ONE application and a separate database per tenant/company so that company users can access their data only and can set security groups inside company if they want to share or hide specific company records within user hierarchy.
Moreover we would like to cap a limit on the database for the companies for the usages (example - if the company database size & storage grows to 500MB we would like to alert the company users on the usage)
Let me know your response on the sameā¦ Cheers
Hi Aiebee
thanks for the quick answer.
A quick question -does your organisation have a dedicated central security team? What does their security audit of this say? Or if your organisation is too small for that - the external security team you are using, what does their audit say?
Because you are holding data that is in most countries legally protected - it would be high risk for your clients and your on company, if you did not have written security audits in place.
EITHER:
- The user logs in - your unique code runs and connects them to the database that is NOT theirs, but another company. Due to an error.
OR - the customer code to ātrapā every single database call and route to the right database; āmissesā out a call and the user sees data from a different client (every change you make to Suite, every plugin used, could accidentally leave a gap)
ROOT CAUSE:
Due to some unknown glitch in your code, that only shows up in the future. Or maybe triggered by a bug in code you did NOT write yourself: eg in some php library, or some Suite code that changed. Or some new XSS vulnerability.
what is the drawback of hosting each client seperatelyResponse aiebee - Maintenance & Upgrade drawbacks
Maybe you can expand on that drawback, give more detail? Because it is surely outweighed by the āmaintenance and upgrade costsā of running a Fork of Suite that has been changed in NEARLY EVERY corner to break the baked-in āone database per instanceā design. You will never be able to try a āquick PRā bug fix from the community; upgrading will never be possible using the standard upgrade tools. Youāll have to write your own.
There is another major downside to having only 1 Suite instance - " all eggs in one basket".
- if/when that fails - it fails for all clients
- no way to use the good engineering practise: " test out new changes on just 10% of clients first"
- lack of scalabilty - no easy way to put heavy-clients (big payers?) onto dedicated, faster hardware/cloud.
My company has some clients who run SaaS systems like Suite (but not CRm - ERP, or HR Rota systems or learning systems): they run seperate systems per client-organisation: albeit those clients have 100s or 1000s of login users.
How many clients do you expect in year 1, year 3 ? and how many users each?
