Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-3769

provide a way to delete a person

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • None
    • None
    • None
    • None

    Description

      Reply…

      Also send to incommon-grouper

      incommon-grouper
      Jason Peak, Michael Gettes, and you

      Jason Peak 4 months ago
      tl;dr; How can you best update Grouper when a person changes their username, which is used for Grouper’s subject_id here at oregonstate.edu ?
      At Oregon State, we use a name-based institutional identifier for subject_id in Grouper. When someone changes their legal name, we allow them to have a new username. Part of that process is to programatically update name information in several systems, including Grouper.
      We recently discovered that the Java we use to update Grouper when someone changes their username has probably been broken for a long time. It uses WsMemberChangeSubjectLiteResult, which seems to need both the new subjectId and the old subjectId to be resolveable in the subject source (we use LDAP) at the time it’s called. Since we’re renaming the object in LDAP, there’s never a moment when both names are in LDAP for Grouper to find.
      We’re thinking of replacing our call to GrouperWS with a direct DB update along these lines: “UPDATE GROUPER_MEMBERS SET subject_id = :new_username WHERE subject_id = :old_username”. Is this a terrible idea :wink: ?

      Chris Hyzer 4 months ago
      unfortunately yes...

      Chris Hyzer 4 months ago
      i mean, that could work if the new subject doesnt have a record in the table yet, which might or might not be the case. I think we need to fix that service. What version are you? Can you get to the latest 2.5 or 2.6? :slightly_smiling_face:
      You could call a GSH to change it... :slightly_smiling_face:
      https://spaces.at.internet2.edu/pages/viewpage.action?pageId=14517859#GrouperShell(gsh)-Memberchangesubject
      Note, we probably need an example of finding the member ID without a resolvable subject... let me know if you want me to post that if GSH is the route you go?
      Another option I was thinking about is a job that takes a SQL view of three cols, subject id "from", and subject id "to", and a timestamp. A grouper daemon would poll that and do the right thing.
      However, that is good for merges, but what about splits (undo a merge). For a split should it use PIT and go back in time for both IDs? What about entitlements assigned between the split and merge? Gets complicated...

      Jason Peak 4 months ago
      Thanks Chris! We’re running 2.5.29, and having just spent 10 minutes skimming all the Jiras, we’re probably due for an upgrade.
      If that doesn’t fix us, the GSH route could be an expedient workaround for the WS.

      Chris Hyzer 4 months ago
      I don’t think it will fix you. I will try to get this in the next release (not the one today)

      Michael Gettes 4 months ago
      @Jason Peak IMHO - you should still upgrade to better position yourself for future upgrades. The more often you do it - the easier it gets and the fear associated with it goes away.

      Jason Peak 4 months ago
      Yeah, thanks Michael, we’re definitely overdue.

      Jason Peak 4 months ago
      Chris, I appreciate your attention to it. The earliest I can imagine us getting Grouper upgraded is in the first week of October, so you know, take your time

      Jason Peak 17 hours ago
      Fast-forward to 2022…
      Happy Friday all,
      tl;dr; how can we delete a subject_id safely?
      We ended up making direct DB updates to subject_id which has been fine, for the most part.
      However, since Grouper doesn’t delete rows from grouper_members, I have to pick a different ‘new username’ every time I test our username change process on our test accounts. A day of heavy testing might require several username changes on our test account from old-username -> new-username (and then reset back to old-username again).
      Our test accounts’ usernames are iamtest[1-7] - 8-char max allowed in our usernames. At this point, our grouper_members table is full of artifacts of old username change tests:
      iamtesta
      iamtestb
      iamtestc

      …we’re running out of letters!
      We would like to clean this mess up with something like “DELETE FROM GROUPER_MEMBER WHERE SUBJECT_ID IN (…)”
      How can we do this safely? (edited)

      Chris Hyzer 17 hours ago
      is the subject unresolvable that you want to remove? do they have any memberships or privileges?

      Chris Hyzer 17 hours ago
      you can remove from members, if you get a foreign key constraint we will need to use the usdu method to remove which deletes those things
      New

      Jason Peak 17 hours ago
      they’re unresolvable, and these are test accounts, so we have zero concern about losing their history or privs or anything in grouper

      Jason Peak 17 hours ago
      I presume we’d also delete from grouper_pit_members in this case?

      Chris Hyzer < 1 minute ago
      @Shilen Patel at some point we can extract the logic to delete a person form the USDU and provide a method right?

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: