Frequently Asked Questions - System Administration
This situation can occur if you are using Enhanced Authentication as a method for encrypting user log in information--and if you installed 3.3 on the same PostgreSQL server instance (i.e., same port) as your old 3.2 database. The problem arises from changes made to user handling in xTuple ERP 3.3.
If this happens to you, there are two options to correct the situation:
1. Disable enhanced authentication and reset the password in either version. Only the passwords of users who logged into 3.3 using Enhanced Authentication will be affected.
2. Or just reset the password in 3.2, keeping Enhanced Authentication enabled in 3.3. Then don't log into 3.3 with that account again.
This situation would have been avoided if the best practices approach of only hosting one database on one PostgreSQL instance had been followed.
The likely reason for this problem is that your PostgreSQL server has not had the Group Role "xtrole" added to it. The "xtrole" Group Role is new in 3.3.0. You won't run into this problem if you're upgrading a 3.2.x database to 3.3.0. It only happens if you're loading a fresh 3.3.0 database from an xTuple backup file.
Here are the steps required to fix the problem via PgAdmin:
- Connect to the server where the database is located (e.g., with pgAdmin)
- Add a new Group Role called "xtrole" having all the same privileges as the "openmfg" role
- Explore the properties of the "openmfg" role and make sure "openmfg" is a member in the "xtrole" Group Role
Here is the SQL to create the xtrole group and add an existing admin user to it:
CREATE GROUP xtrole; GRANT xtrole TO admin;
Here is the SQL to create the xtrole group, create the admin user and make the admin user a member of that group (use this for new installations)
CREATE GROUP xtrole; CREATE USER admin WITH PASSWORD 'admin' CREATEDB CREATEUSER IN GROUP xtrole;
That should be all you need to do. Now log in with your xTuple ERP client.
That's called CIDR notation. Here's a handly calculator for figuring out an appropriate value: http://www.subnet-calculator.com/cidr.php You need to know a little about the network you're setting the server up on and a bit about subnetting. A client may need to allow various networks to connect - they may have several subnets, etc - each network from where you want to allow connections from needs to have an entry in the pg_hba.conf, or at least a rule that fits. 0.0.0.0 is a catch-all - any address will match with that rule. But, suppose you have a remote office, with a fixed IP on their router - all traffic from inside the office goes out with the same WAN IP of that router, say the WAN IP is 129.42.60.216 - that's a single address from a single device. So, on your postgres server where they are connecting to you would create a pg_hba.conf entry similar to: host all all 129.42.60.216/32 md5 /32 is the same as 255.255.255.255 ( 1 address) /24 is the same as 255.255.255.0 (254 addresses) Also, keep in mind that the pg_hba.conf file is read top to bottom. As soon as Postgres finds a rule that allows access, it stops reading rules - so make sure your access rules make sense. You can do all sorts of interesting things with the pg_hba.conf. Read the comments at the top of that file.
The quick and dirty answer is you can right click and export from any list in the application. The more advanced option is to use the xTuple API.
You can read more about using the API to export from xTuple ERP in the docs section.
There are two methods for importing data into the database of xTuple ERP.
- CSVimp
First, xTuple offers a free application called CSVimp that is designed to import Comma Separated Value (CSV) files into the database for the xTuple Applications (The same tool works for PostBooks, Standard and Manufacturing Editions). You can download CSVimp from our SourceForge project site. And detailed instructions for using CSVimp are available in our documents section. - xTuple API
The second method is to use the API. The goal of the xTuple Application Programmer Interface (API) is to make importing data directly into the database much safer and easier than it is going directly into the regular table structure. Our appoach is to allow users to create, access, and update xTuple documents using a special database schema that closely mirrors the graphical user interface (GUI). You can read more about using the API to import data into xTuple ERP in the docs section.
