From 36657a66d29aa7a2f12396ba1b274db764bf58b5 Mon Sep 17 00:00:00 2001 From: Jonas Bardino Date: Tue, 4 Nov 2025 08:41:02 +0100 Subject: [PATCH 1/2] Adjust the naming to refer to end date rather than expire for peers. Hopefully that will reduce the confusion about the difference between the date that the local contact puts as hard end date and the individual account access expire value. The latter needs at least annual renewal and the users can handle that themselves until end date. --- mig/shared/functionality/peers.py | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/mig/shared/functionality/peers.py b/mig/shared/functionality/peers.py index f24f01f4e..31af61dd4 100755 --- a/mig/shared/functionality/peers.py +++ b/mig/shared/functionality/peers.py @@ -91,7 +91,7 @@ def main(client_id, user_arguments_dict): logger.info("%s begin for %s" % (op_name, client_id)) # IMPORTANT: single line here to avoid breaking javascript inlining - expire_help = "For security reasons peer accounts should be closed when no longer required. Expire is used to limit account access time for that purpose, and you can always extend it later if needed. For courses and workshops a few weeks or months should usually suffice, while projects and long-term collaboration often extend to months or years. Peer accounts still need to be renewed at least annually, but the peer users can do so themselves without your repeated explicit acceptance, as long as it does not exceed your provided expire date." + expire_help = "For security reasons peer accounts should be closed when no longer required. End date is used to limit account access time for that purpose, and you can always extend it later if needed. For courses and workshops a few weeks or months should usually suffice, while projects and long-term collaboration often extend to months or years. Peer accounts still need to be renewed at least annually, but the peer users can do so themselves without your repeated explicit acceptance, as long as it does not exceed your provided end date." # jquery support for tablesorter and confirmation on delete # table initially sorted by col. 5 (kind), then 0 (name) @@ -251,13 +251,13 @@ def main(client_id, user_arguments_dict):
-
''' @@ -332,11 +332,11 @@ def main(client_id, user_arguments_dict): 'object_type': 'link', 'destination': "javascript: confirmDialog(%s, '%s', '%s', %s);" % - ('peer_action', 'Update %(full_name)s (%(email)s) expire date (YYYY-MM-DD)?' % filled_entry, + ('peer_action', 'Update %(full_name)s (%(email)s) end date (YYYY-MM-DD)?' % filled_entry, 'peers_expire', "{action: 'update', peers_label: '%(label)s', peers_kind: '%(kind)s', peers_content: '%(distinguished_name)s', peers_invite: false}" % filled_entry), 'class': 'editlink iconspace', - 'title': 'Update %(distinguished_name)s Expire value in peers' % filled_entry, + 'title': 'Update %(distinguished_name)s End date value in peers' % filled_entry, 'text': ''} filled_entry['invitepeerlink'] = { 'object_type': 'link', @@ -533,10 +533,10 @@ def main(client_id, user_arguments_dict):

If someone requests an external user account on %(site)s and explicitly -references you as peers contact person the site admins will generally forward -the request, so that it shows up here for you to confirm. You can then accept -or reject the individual requests below to let the site admins proceed with -account creation or rejection. Please select an expire date to provide limited +references you among contact persons (peers) the site admins will generally +forward the request, so that it shows up here for you to confirm. You can then +accept or reject the individual requests below to let the site admins proceed +with account creation or rejection. Please select an end date to provide limited but sufficiently long account access - it can always be extended later.

''' From 7f9538f3541e91660f02bc49bbd9a5fa3ea05cd5 Mon Sep 17 00:00:00 2001 From: Jonas Bardino Date: Tue, 4 Nov 2025 09:09:32 +0100 Subject: [PATCH 2/2] Fix a few more references to expire/expiry on Peers page tabs and update copyright header. Tested in deployment. Minor style fixes from autopep8. --- mig/shared/functionality/peers.py | 12 ++++++------ mig/shared/output.py | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/mig/shared/functionality/peers.py b/mig/shared/functionality/peers.py index 31af61dd4..1f4587b11 100755 --- a/mig/shared/functionality/peers.py +++ b/mig/shared/functionality/peers.py @@ -4,7 +4,7 @@ # --- BEGIN_HEADER --- # # peers - manage external collaboration partners, etc. -# Copyright (C) 2003-2021 The MiG Project lead by Brian Vinter +# Copyright (C) 2003-2025 The MiG Project by the Science HPC Center at UCPH # # This file is part of MiG. # @@ -305,7 +305,7 @@ def main(client_id, user_arguments_dict): vouched for to get an account on %(site)s because they need it for a particular course/workshop, research project or for general long term collaboration with you. The site admins will use this information to accept account requests and -extensions from your peers until the given time of expiry. +extensions from your peers until the given end date.

''' @@ -376,10 +376,10 @@ def main(client_id, user_arguments_dict):

You may enter your individual peers in the form fields below and assign a -shared kind and account expiry time for all entries. Just leave the Action -field to Add unless you want to Update or Remove -existing peers. You are free to leave rows empty, but each field in a peer row -MUST be filled for the row to be treated. +shared kind and account end date for all entries. Just leave the Action field +to Add unless you want to Update or Remove existing +peers. You are free to leave rows empty, but each field in a peer row MUST be +filled for the row to be treated.

%(form_prefix_html)s diff --git a/mig/shared/output.py b/mig/shared/output.py index 74517410f..6701c8e0a 100644 --- a/mig/shared/output.py +++ b/mig/shared/output.py @@ -1530,7 +1530,7 @@ def html_format(configuration, ret_val, ret_msg, out_obj): State Kind Label - Expire + End Date Actions