comanage-dev - [comanage-dev] Notes: COmanage dev call, 10 July 2015
Subject: COmanage Developers List
List archive
- From: Heather Flanagan <>
- To:
- Subject: [comanage-dev] Notes: COmanage dev call, 10 July 2015
- Date: Fri, 10 Jul 2015 10:50:27 -0700
Attendees:
Scott, Arlen, Heather, Benn
Discussion topics:
1. LIGO Gap analysis (Scott)
- status of adding a second role to a CO Person record through
and enrollment, needs to be enrollment because addition of
that role usually means "joining" a COU and the admin for
that COU needs to approve, also maybe adding a role like
"student" or "staff"--any addition of extra "affiliation"
may need approval
(This may also be needed for GÉANT.)
See:
https://spaces.internet2.edu/display/COmanage/Understanding+Registry+Enrollment+and+Linking#UnderstandingRegistryEnrollmentandLinking-AdditionalRoleEnrollment
- can an approver edit text of email to be sent if this is
done using an enrollment plugin? (#15 on Mike's page)
This would be for when a petition is a approved/denied so that the
approver can add text as to why it was approved or denied. One can add
comments to the petition itself, but that won't go to an enrollee. Right
now, you can't do this in a way that the enrollee can see it; this would
need development time.
- in the new enrollments, how much control will there be to
present MOUs (COUs?) that a user may or may not join?
See the COU popup list ticket from Mike. Right now, you would need a
per-COU enrollment flow. In terms of puplating COU lists, someone would
have to write that code. It's not really a plug-in.
- better identity linking during anonymous enrollment because
about half of user support issues are duplicate
enrollments/registrations (people tend to register again
just because they have forgot a "password", or they just
change name and register again)
Maybe an Arlen thing?
Not convinced this is exactly what they want. Need to determine how each
enrollment process works with duplicate entries. Think: workflow and
business process more than technical work.
2. View variables question (Scott)
Debugging the problem Ken saw in the LARPP platform
somewhere between when the controller ends and the view writer starts,
something is overwriting CO_view variable. Probably the appcontroller;
Scott to follow up and fix.
3. Search and Filter (Arlen)
- How badly do we want a generic search that searches co people, org
ids, and groups? Anything else to be searched?
- Do we want a group filter/search box (such as exists on co_people and
org_identities), and if so are we searching for groups or for people
that return groups? Both?
Benn is inclined to deprioritize this; some of the functionality can be
handled through the selectors.
4. CO-974 (Arlen)
- Merge co_person_roles Into co_people/canvas - do we want to try and
tackle this? To make it quick, it would likely need to be done as an
iframed lightbox.
Depends on how much time this will take. May not be particularly time
consuming.
There might be a generic search functionality in here (a "cross-model
search") that is more efficient to work on.
5. Test user question (Arlen)
Need at least 4 test users. Note that one of the problems here will be
fixed as the View Variable above is fixed.
Users needed: authenticated user (but not in any COs), CO admin, normal
user, platform admin
- [comanage-dev] Notes: COmanage dev call, 10 July 2015, Heather Flanagan, 07/10/2015
Archive powered by MHonArc 2.6.16.