...
[15:02:51 CDT(-0500)] <athena> maybe you could describe what you're trying to do there?
[15:03:43 CDT(-0500)] <drewwills> allow non-local accounts to have some attributes set in the uPortalAccountUserSource
[15:04:11 CDT(-0500)] <EricDalquist> seems reasonable
[15:04:18 CDT(-0500)] <drewwills> i'd like to be able to click the "Edit" buttn on a non-local account in User Manager
[15:04:30 CDT(-0500)] <EricDalquist> so an account from some exterior source is also pulling in user attributes from the local db
[15:04:41 CDT(-0500)] <athena> would probably need additional configuration to specify exactly which attributes can be persisted, and for which group
[15:04:44 CDT(-0500)] <drewwills> yep, that's it in a nutshell
[15:05:23 CDT(-0500)] <drewwills> i'd like to develop the wiki page we started to form a plan in that respect
[15:05:33 CDT(-0500)] <athena> ok
[15:05:39 CDT(-0500)] <athena> what do we think of what's on the wiki page now?
[15:06:15 CDT(-0500)] <drewwills> i think i may not have visited since the last change... will do so
[15:06:24 CDT(-0500)] <drewwills> i have to hop on a quick call though
[15:28:31 CDT(-0500)] <drewwills> athena it looks like your notes imagine tackling these changes (at least partially) through the PersonDir API, which I would agree with
[15:28:54 CDT(-0500)] <drewwills> it may be an opportunity to apply some polish there... smooth over some rough edges
[15:30:04 CDT(-0500)] <drewwills> I wonder if we need some sort of IPersonAttributeDaoMetaData type
[15:30:18 CDT(-0500)] <drewwills> so that DAOs can tell you what features they support
[15:30:29 CDT(-0500)] <drewwills> and so forth
[15:30:38 CDT(-0500)] <EricDalquist> I would do this in teh spirit of PD
[15:30:41 CDT(-0500)] <EricDalquist> and NOT as part of that API
[15:30:50 CDT(-0500)] <EricDalquist> that is going to be nightmare to make that API 2 way
[15:31:56 CDT(-0500)] <drewwills> have you ever considered @Depricating IPersonAttributeDao, then starting over with a much simpler API and class hierarchy?
[15:32:02 CDT(-0500)] <EricDalquist> yes
[15:32:10 CDT(-0500)] <EricDalquist> I have a bunch of notes on paper on doing just that
[15:32:15 CDT(-0500)] <drewwills> you could re-impl the old api on the back of the new
[15:32:49 CDT(-0500)] <drewwills> if that work were done, do you think 2 way would be less of a nightmare?
[15:33:19 CDT(-0500)] <EricDalquist> that would require redesign of my current on-paper notes
[15:33:28 CDT(-0500)] <EricDalquist> so it could be considered as a feature for the redesign work
[15:33:41 CDT(-0500)] <EricDalquist> but right now I think the best bet is a small out-of-band add on
[15:33:54 CDT(-0500)] <EricDalquist> essentially like athena described
[15:33:54 CDT(-0500)] <athena> drewwills: i should have made that more clear. actually i didn't think using person directory was going to be a good idea
[15:33:55 CDT(-0500)] <drewwills> fwiw i think that if personDir were easier to grok & configure, they'd be lining up to thank you at the next conference
[15:34:05 CDT(-0500)] <EricDalquist> oh I know
[15:34:07 CDT(-0500)] <athena> perhaps it'd be better to name that interface more clearly to signal that separation
[15:34:25 CDT(-0500)] <drewwills> yes athena I think it would be
[15:34:30 CDT(-0500)] <EricDalquist> a service that handles describing which attributes are mutable for which groups
[15:34:38 CDT(-0500)] <EricDalquist> and then a dao interface for doing that
[15:34:41 CDT(-0500)] <athena> right
[15:34:47 CDT(-0500)] <EricDalquist> and then for your need you can write an impl that goes to ldap
[15:34:49 CDT(-0500)] <EricDalquist> or local accounts
[15:34:51 CDT(-0500)] <EricDalquist> or whatever
[15:34:52 CDT(-0500)] <athena> i think that's roughly what the wiki describes?
[15:34:55 CDT(-0500)] <EricDalquist> yup
[15:35:01 CDT(-0500)] <EricDalquist> and we take that as a note
[15:35:06 CDT(-0500)] <EricDalquist> and keep it in mind for a PD rewrite
[15:35:41 CDT(-0500)] <athena> so other than the naming change, are there other things we'd like on that wiki plan?
[15:36:57 CDT(-0500)] <drewwills> fyi the main side effect of the patch i posted seems to be that you can enter a password for local auth
[15:37:11 CDT(-0500)] <drewwills> don't know it that's a feature or a bug
[15:37:37 CDT(-0500)] <EricDalquist> depends on how you have your security config setup
[15:37:39 CDT(-0500)] <EricDalquist> if you have local auth off it doesn't matter
[15:37:51 CDT(-0500)] <drewwills> that's true
[15:38:12 CDT(-0500)] <athena> right
[15:38:18 CDT(-0500)] <athena> so depends on what you want and what you want the permissions to be
[15:38:33 CDT(-0500)] <athena> i think the plan in the wiki would cover this, since you could simply leave password off the list for everyone but local users
[15:38:39 CDT(-0500)] <EricDalquist> yup
[15:38:47 CDT(-0500)] <athena> and we could assume that attributes that aren't persistable shouldn't be in the editing interface
[15:39:21 CDT(-0500)] <drewwills> sounds good
[15:39:30 CDT(-0500)] <athena> and then your line to actually create a user should be in the local-specific implementation, of course
[15:41:01 CDT(-0500)] <drewwills> i think i follow... the dao.createUser() call would get moved into the LocalPersistingPersonAttributeDAO?
[15:41:23 CDT(-0500)] <drewwills> and the useraccounthelper would know about IPersistingPersonAttributeDAOs?
[15:41:37 CDT(-0500)] <drewwills> something along those lines
[15:42:31 CDT(-0500)] <athena> yeah
[15:44:46 CDT(-0500)] <drewwills> for the moment, do you think the ability to edit attributes for non-local users should be a config setting? (this line – if (false / TODO: config / && !isLocalAccount(target)) {) and if so, should it be on or off?
[15:45:45 CDT(-0500)] <drewwills> i would say it should, but I know there's sometimes issues with options that are off by default and atrophy
[15:46:35 CDT(-0500)] <athena> no, i don't think we need a boolean setting there
[15:47:13 CDT(-0500)] <athena> if there aren't any non-local user attribute mappings provided, it'll have the effect of not persisting credentials anywhere else
[15:47:41 CDT(-0500)] <drewwills> yeah we wouldn't want that
[15:48:35 CDT(-0500)] <drewwills> a couple questions about this line: The configuration should enable statements like "Persist user attribute 'a' via persistence implmenetation 's' for users in group g".
[15:48:51 CDT(-0500)] <drewwills> (1) is that user-manager config? or something broader
[15:49:42 CDT(-0500)] <athena> i think that maps to what eric described as "a service that handles describing which attributes are mutable for which groups"
[15:49:54 CDT(-0500)] <athena> so no, that's not user-manager config
[15:49:59 CDT(-0500)] <drewwills> (2) would the config be a list of these: <bean class="org.jasig.portal.portlets.account.PreferenceInputFactory" factory-method="createSingleTextPreference"><constructor-arg value="telephoneNumber"/><constructor-arg value="attribute.displayName.telephoneNumber"/></bean>
[15:50:25 CDT(-0500)] <athena> the config needs to be something more than that - needs to include the group and DAO impl mapping
[15:50:32 CDT(-0500)] <athena> but yes, plausible that it should also include the input method
[15:50:52 CDT(-0500)] <athena> since that'll help with constructing the UI
[15:51:20 CDT(-0500)] <athena> and really maybe even good to have those explicitly part of the config, since perhaps the same attribute could have different plausible values depending on which system it was persisted to
[15:51:28 CDT(-0500)] <drewwills> could be a Map of daoDescriptor (group & dao mapping) to inputs
[15:53:20 CDT(-0500)] <athena> Map<groupName, Map<attributeName, Descriptor(daoImpl, input)>>?
[15:53:45 CDT(-0500)] <athena> where the group mapping is actually ordered, so that you can get consistent behavior
[15:53:54 CDT(-0500)] <athena> or maybe that can just be a list
[15:54:30 CDT(-0500)] <athena> List<GroupMappingThing(groupName, Map<attributeName, Descriptor(daoImpl, input)>)>
[15:57:09 CDT(-0500)] <drewwills> I'm going to try to capture some of this on the page
[16:52:28 CDT(-0500)] <rlewis> Hi, I am trying to use uportal-4.0.6.SR1-quick-start with MySQL and when I run "ant dbtest" it downloads dependencies then "Invoking DbTest" and " WARN [33:09,849] Failed to register connection pool with MBeanServer. JMX information will not be available for: RawEventsDb [java] java.sql.SQLException: org.mysql.jdbc.Driver [java] at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.j
[17:01:14 CDT(-0500)] <sjungling> Hi all, launched uP 4.0.5 this morning. For the most part everything is going smoothly. Our DBA is noticing that we're getting some row lock contention (Oracle 11g) on queries that seem to deal with Event Logging like:
[17:01:14 CDT(-0500)] <sjungling> update UP_EVENT_AGGR_STATUS set ENTITY_VERSION=:1, LAST_END=:2, LAST_EVENT_DATE=:3, LAST_START=:4, SERVER_NAME=:5 where ID=:6and ENTITY_VERSION=:7
[17:01:14 CDT(-0500)] <sjungling> anyone else experienced this and / or know how to disable Event Logging / Aggregation altogether?