I've been digging through the OFBiz permissions infrastructure to better understanding the workflow. Thought I'd share some thoughts and findings...
A permission is a combination of an application (entity) and an action: e.g. FACILITY_UPDATE. There is the typical approach of user X has permission Y, so let the action proceed. There is an additional concept of context-specific permission roles. For example, if user X needs permission to update certain facilities, but not all of them, user X would be given the FACILITY_ROLE_UPDATE permission and one or more Roles would be created which link the user to a specific set of facilities. Role based permissions are not quite as common from what I can tell, but they will give us a way to limit what data librarians are able to create/view/update/delete, both from the UI perspective as well as in the business logic. As far as users go, OFBiz has Party's, which can be thought of as abstract entities, manifesting themselves as Person's or PartyGroups. How do we integrate users and permissions with Evergreen? 1. Is single sign-on a requirement between the staff client and the ACQ system? Yes 2. Is it a requirement that Evergreen user objects "magically exist" inside the ACQ system? Meaning, it should not be necessary for an admin to manually create users in the ACQ system if they already exist in EG. I'd say yes. 3. As an addendum, should it be impossible for an admin to create a user in the ACQ system if the user does not exist in Evergreen DB? I'd say yes, if the above is true. 4. Should the system avoid duplication of information by /not/ storing user objects directly in the ACQ system. I'd say NO to this, mainly because I'm concerned about the development effort required to extract these heavily used objects from the OFBiz core. There is a whitepaper at http://docs.ofbiz.org/download/attachments/440/EELDAP-analysis-finaldraft.pdf, which posits an LDAP plugin could be built for OFBiz, which would allow an external user database, by a competent engineer in 60-80 hours. Evergreen isn't LDAP, but the mapping process would be similar. Given that none of us (that I know of) are experts in OFBiz internals, I'd say that's an optimistic time estimate. What I'm imagining is the Evergreen staff client passing the usual Evergreen auth token as a URL param to the OFBiz interface. A pre-login process will perform the following: - load the user from the EG database - make sure the user is active and has ACQ_LOGIN (or similar) perms. - check to make sure this user is represented in the OFBiz DB and, if not, create a record for the user in the OFBiz DB. - continue with login Make sense? I'm not sure how this will work exactly, but I'm confident it can be done. Let me know if I'm being short-sighted, unnecessarily complex, or completely off base with any of this. This email is getting too long :) We haven't even gotten into groups and perms yet. More questions to come... -bill -- Bill Erickson Equinox Software, Inc. [EMAIL PROTECTED] http://esilibrary.com/
