If you are loading ogo_account, ogo_team, ogo_team_membership, ogo_project, and ogo_project_access tables with the appropriate methods you can easily simulate project access in your foriegn database by creating the following view -

CREATE VIEW v_ogo_project_access (project_id, permissions, team_name, login) AS SELECT ogo_project_access.project_id, TRIM(ogo_project_access.permissions) AS permissions, "n/a" AS team_name, TRIM(ogo_account.login) AS login FROM ogo_project_access, ogo_account WHERE ogo_account.account_id = ogo_project_access.object_id UNION SELECT ogo_project_access.project_id, TRIM(ogo_project_access.permissions) AS permissions, ogo_team.name AS team_name, TRIM(ogo_account.login) AS login FROM ogo_project_access, ogo_team, ogo_account, ogo_team_membership WHERE ogo_project_access.object_id = ogo_team.team_id AND ogo_team.team_id = ogo_team_membership.team_id AND ogo_team_membership.account_id = ogo_account.account_id

• this constructs a list of all permissions granted to a user either specifically (by their login) or by virtue of a team membership.

So, for instance, you can determine what projects user "awilliam" has access to with a query like -

SELECT project_id, name FROM ogo_project WHERE project_id IN (SELECT project_id FROM v_ogo_project_access WHERE login = awilliam AND permissions LIKE (%r%))

• which will return only the project_id and name of projects to with the user awilliam has read access.

For instance, we have an external intranet application used to track quality control issues. The QC personel have an optional field they can use to associate a QC issue with an OpenGroupware project, and we only want them to be able to pick from projects they can see normally in OpenGroupware. Since the list of projects is very long doing an XML-RPC get and parse every time the user uses the form is a bit slow and unwieldy, so we simply sync the project list and permissions on a periodic basis to another database.