...
[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?