internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: ietf-tools/datatracker

Issue:
How do I kill a chartering effort?
### Describe the issue

See https://datatracker.ietf.org/doc/charter-ietf-term/

I set the charter document state to "Not currently under review" and the WG state to "Abandoned", but it is still showing up on https://datatracker.ietf.org/doc/ad/lars.eggert

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:
Cindy found an older closed related issue at #2889.

I suspect we need to filter this in the logic for the /doc/ad/ view.

Resolving patch:
diff --git a/ietf/doc/views_search.py b/ietf/doc/views_search.py
--- a/ietf/doc/views_search.py
+++ b/ietf/doc/views_search.py
@@ -679,7 +679,27 @@ def docs_for_ad(request, name):
     results, meta = prepare_document_table(request, retrieve_search_results(form), form.data, max_results=500)
     results.sort(key=ad_dashboard_sort_key)
     del meta["headers"][-1]
-    #
+
+    # filter out some results
+    results = [
+        r
+        for r in results
+        if not (
+            r.type_id == "charter"
+            and (
+                r.group.state_id == "abandon"
+                or r.get_state_slug("charter") == "replaced"
+            )
+        )
+        and not (
+            r.type_id == "draft"
+            and (
+                r.get_state_slug("draft-iesg") == "dead"
+                or r.get_state_slug("draft") == "repl"
+            )
+        )
+    ]
+
     for d in results:
         d.search_heading = ad_dashboard_group(d)
     #


Test patch:
Repository: ietf-tools/datatracker

Issue:
Wording change on /secr/sreq
### Description

Requested by @flynnliz, please change, "You should not include the Area Directors; they will be added automatically," to something like, "You should not include your Area Director; the tool accounts for their conflicts separately," to avoid giving the impression that the AD's name will actually appear in the field.

People seem to add the AD anyway. Would be nice to prevent this because even the rephrasing may not discourage it enough.

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:
(Don't accept data you don't want to process...)
See #3890

Resolving patch:
diff --git a/ietf/secr/sreq/forms.py b/ietf/secr/sreq/forms.py
--- a/ietf/secr/sreq/forms.py
+++ b/ietf/secr/sreq/forms.py
@@ -3,6 +3,7 @@
 
 
 from django import forms
+from django.template.defaultfilters import pluralize
 
 import debug                            # pyflakes:ignore
 
@@ -235,6 +236,25 @@ def clean_joint_with_groups(self):
     def clean_comments(self):
         return clean_text_field(self.cleaned_data['comments'])
 
+    def clean_bethere(self):
+        bethere = self.cleaned_data["bethere"]
+        if bethere:
+            extra = set(
+                Person.objects.filter(
+                    role__group=self.group, role__name__in=["chair", "ad"]
+                )
+                & bethere
+            )
+            if extra:
+                extras = ", ".join(e.name for e in extra)
+                raise forms.ValidationError(
+                    (
+                        f"Please remove the following person{pluralize(len(extra))}, the system "
+                        f"tracks their availability due to their role{pluralize(len(extra))}: {extras}."
+                    )
+                )
+        return bethere
+
     def clean_send_notifications(self):
         return True if not self.notifications_optional else self.cleaned_data['send_notifications']
 


Test patch:
Repository: ietf-tools/datatracker

Issue:
Profile page Active Drafts sections need improved filters for drafts that have become RFCs
### Describe the issue

Hi, 

We received a ticket that on this person record (https://datatracker.ietf.org/person/ludwig@clemm.org) it lists a nonactive wg ([draft-clemm-nmrg-dist-intent](https://datatracker.ietf.org/doc/draft-clemm-nmrg-dist-intent/)) as Active. 

Ticket: https://rt5.ietf.org/Ticket/Display.html?id=14903

Jenny 

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:
The problem is here:

https://github.com/ietf-tools/datatracker/blob/02f8bf20ef31024ecec4eddf56a2e969ba90b6bb/ietf/person/models.py#L188-L190

There is more than one state machine with `active` as a state. In the case reported above, the RG state machine is still in the `active` state.

The query above should be modified to match only the `draft` state machine.

Similar adjustments should be made to the queries around it.

Resolving patch:
diff --git a/ietf/person/models.py b/ietf/person/models.py
--- a/ietf/person/models.py
+++ b/ietf/person/models.py
@@ -187,12 +187,31 @@ def rfcs(self):
 
     def active_drafts(self):
         from ietf.doc.models import Document
-        return Document.objects.filter(documentauthor__person=self, type='draft', states__slug='active').distinct().order_by('-time')
+
+        return (
+            Document.objects.filter(
+                documentauthor__person=self,
+                type="draft",
+                states__type="draft",
+                states__slug="active",
+            )
+            .distinct()
+            .order_by("-time")
+        )
 
     def expired_drafts(self):
         from ietf.doc.models import Document
-        return Document.objects.filter(documentauthor__person=self, type='draft', states__slug__in=['repl', 'expired', 'auth-rm', 'ietf-rm']).distinct().order_by('-time')
 
+        return (
+            Document.objects.filter(
+                documentauthor__person=self,
+                type="draft",
+                states__type="draft",
+                states__slug__in=["repl", "expired", "auth-rm", "ietf-rm"],
+            )
+            .distinct()
+            .order_by("-time")
+        )
 
     def save(self, *args, **kwargs):
         created = not self.pk


Test patch:
Repository: ietf-tools/datatracker

Issue:
editorial refactor broke the main menu
The main menu link for the Editorial stream (/stream/editorial) now 404s.



Discussion:
the whole /stream/ URL stem needs rethinking - its is only useful for some of the streams. /stream/ietf also 404s, but nothing points to it.

Resolving patch:
diff --git a/ietf/group/views.py b/ietf/group/views.py
--- a/ietf/group/views.py
+++ b/ietf/group/views.py
@@ -1283,6 +1283,8 @@ def streams(request):
     return render(request, 'group/index.html', {'streams':streams})
 
 def stream_documents(request, acronym):
+    if acronym == "editorial":
+        return HttpResponseRedirect(urlreverse(group_documents, kwargs=dict(acronym="rswg")))
     streams = [ s.slug for s in StreamName.objects.all().exclude(slug__in=['ietf', 'legacy']) ]
     if not acronym in streams:
         raise Http404("No such stream: %s" % acronym)


Test patch:
diff --git a/ietf/group/tests.py b/ietf/group/tests.py
--- a/ietf/group/tests.py
+++ b/ietf/group/tests.py
@@ -17,7 +17,7 @@
 
 import debug                             # pyflakes:ignore
 
-from ietf.doc.factories import DocumentFactory, WgDraftFactory
+from ietf.doc.factories import DocumentFactory, WgDraftFactory, EditorialDraftFactory
 from ietf.doc.models import DocEvent, RelatedDocument, Document
 from ietf.group.models import Role, Group
 from ietf.group.utils import get_group_role_emails, get_child_group_role_emails, get_group_ad_emails
@@ -41,6 +41,11 @@ def test_stream_documents(self):
         self.assertEqual(r.status_code, 200)
         self.assertContains(r, draft.name)
 
+        EditorialDraftFactory() # Quick way to ensure RSWG exists.
+        r = self.client.get(urlreverse("ietf.group.views.stream_documents", kwargs=dict(acronym="editorial")))
+        self.assertRedirects(r, expected_url=urlreverse('ietf.group.views.group_documents',kwargs={"acronym":"rswg"}))
+
+
     def test_stream_edit(self):
         EmailFactory(address="ad2@ietf.org")
Repository: ietf-tools/datatracker

Issue:
agenda.csv is badly formatted
### Describe the issue

The CSV agenda at `/meeting/agenda.csv` is badly formatted:
```
"b'Date'","b'Start'","b'End'","b'Session'","b'Room'","b'Area'","b'Acronym'","b'Type'","b'Description'","b'Session ID'","b'Agenda'","b'Slides'"
"b'2023-03-25'","b'0030'","b'1200'","b'None'","b'G3'","b''","b'hackathon'","b'GEN'","b'Hackathon'","30188","",""
"b'2023-03-25'","b'0100'","b'0900'","b'None'","b'G416'","b''","b'tools'","b'GEN'","b'Code Sprint'","30399","",""
```
This is probably because byte strings are being passed to the csv writer when it expects strings or a similar error.

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:

Resolving patch:
diff --git a/ietf/meeting/views.py b/ietf/meeting/views.py
--- a/ietf/meeting/views.py
+++ b/ietf/meeting/views.py
@@ -1805,18 +1805,18 @@ def agenda_extract_slide (item):
     }
 
 def agenda_csv(schedule, filtered_assignments):
-    response = HttpResponse(content_type="text/csv; charset=%s"%settings.DEFAULT_CHARSET)
+    encoding = 'utf-8'
+    response = HttpResponse(content_type=f"text/csv; charset={encoding}")
     writer = csv.writer(response, delimiter=str(','), quoting=csv.QUOTE_ALL)
 
     headings = ["Date", "Start", "End", "Session", "Room", "Area", "Acronym", "Type", "Description", "Session ID", "Agenda", "Slides"]
 
     def write_row(row):
-        encoded_row = [v.encode('utf-8') if isinstance(v, str) else v for v in row]
-
-        while len(encoded_row) < len(headings):
-            encoded_row.append(None) # produce empty entries at the end as necessary
-
-        writer.writerow(encoded_row)
+        if len(row) < len(headings):
+            padding = [None] * (len(headings) - len(row))  # produce empty entries at the end as necessary
+        else:
+            padding = []
+        writer.writerow(row + padding)
 
     def agenda_field(item):
         agenda_doc = item.session.agenda()


Test patch:
Repository: ietf-tools/datatracker

Issue:
apikey/del should not offer already disabled api keys
`type_defect`   |    by kesara@staff.ietf.org

___


The issue here is the when a user tries to disable an API key from /accounts/apikey

They are taken to view where all the API keys (including disabled ones) are listed in a dropdown.

If the user selects an already disabled API key...

The view should be modified to not offer disabled keys.

___
_Issue migrated from trac:3441 at 2022-03-04 09:17:36 +0000_


Discussion:
_@rjsparks@nostrum.com_ _changed status from `new` to `accepted`_

Resolving patch:
diff --git a/ietf/ietfauth/views.py b/ietf/ietfauth/views.py
--- a/ietf/ietfauth/views.py
+++ b/ietf/ietfauth/views.py
@@ -777,7 +777,7 @@ class Meta:
 @person_required
 def apikey_disable(request):
     person = request.user.person
-    choices = [ (k.hash(), str(k)) for k in person.apikeys.all() ]
+    choices = [ (k.hash(), str(k)) for k in person.apikeys.exclude(valid=False) ]
     #
     class KeyDeleteForm(forms.Form):
         hash = forms.ChoiceField(label='Key', choices=choices)


Test patch:
Repository: ietf-tools/datatracker

Issue:
Unused Meeting.session_constraintnames property should be removed
`type_cleanup`   |    by jennifer@painless-security.com

___


The `session_constraintnames` `@property` was added to `Meeting` in fixing #3083. This was a temporary feature replaced by the changes for #2770, as indicated in the comments. This method should be removed as it is unused and unneeded.

___
_Issue migrated from trac:3389 at 2022-03-04 09:12:18 +0000_


Discussion:
_@rjsparks@nostrum.com_ _changed priority from `n/a` to `medium`_
_@rjsparks@nostrum.com_ _changed status from `new` to `accepted`_

Resolving patch:
diff --git a/ietf/meeting/models.py b/ietf/meeting/models.py
--- a/ietf/meeting/models.py
+++ b/ietf/meeting/models.py
@@ -298,26 +298,6 @@ def proceedings_format_version(self):
             self._proceedings_format_version = version  # save this for later
         return self._proceedings_format_version
 
-    @property
-    def session_constraintnames(self):
-        """Gets a list of the constraint names that should be used for this meeting
-
-        Anticipated that this will soon become a many-to-many relationship with ConstraintName
-        (see issue #2770). Making this a @property allows use of the .all(), .filter(), etc,
-        so that other code should not need changes when this is replaced.
-        """
-        try:
-            mtg_num = int(self.number)
-        except ValueError:
-            mtg_num = None  # should not come up, but this method should not fail
-        if mtg_num is None or mtg_num >= 106:
-            # These meetings used the old 'conflic?' constraint types labeled as though
-            # they were the new types.
-            slugs = ('chair_conflict', 'tech_overlap', 'key_participant')
-        else:
-            slugs = ('conflict', 'conflic2', 'conflic3')
-        return ConstraintName.objects.filter(slug__in=slugs)
-
     def base_url(self):
         return "/meeting/%s" % (self.number, )
 


Test patch:
Repository: ietf-tools/datatracker

Issue:
Propagating https://datatracker.ietf.org/meeting/upcoming.ics awareness in the community
`type_enhancement`   |    by spencerdawkins.ietf@gmail.com

___


I discovered https://datatracker.ietf.org/meeting/upcoming.ics while I was on the IESG, but it still seems to be one of the best-kept secrets at the IETF, and since we are likely to be in a swarm of upcoming virtual meetings at least until IETF 108, and possibly beyond, could you think a bit about where this URL could appear, to increase community awareness? 

I was thinking "perhaps in the e-mail that announces that a meeting has been scheduled", like at the bottom of https://mailarchive.ietf.org/arch/msg/ietf-announce/ukPynjBvA9UapJ-TAaWRAtcI2Rc/, but you folks probably know best. 

___
_Issue migrated from trac:2939 at 2022-03-04 07:46:37 +0000_


Discussion:
_@rjsparks@nostrum.com_ _changed status from `new` to `under_review`_

Resolving patch:
diff --git a/ietf/meeting/helpers.py b/ietf/meeting/helpers.py
--- a/ietf/meeting/helpers.py
+++ b/ietf/meeting/helpers.py
@@ -826,7 +826,7 @@ def get_announcement_initial(meeting, is_change=False):
         desc=desc,
         date=meeting.date,
         change=change)
-    body = render_to_string('meeting/interim_announcement.txt', locals())
+    body = render_to_string('meeting/interim_announcement.txt', locals() | {"settings": settings})
     initial['body'] = body
     return initial
 


Test patch:
diff --git a/ietf/meeting/tests_views.py b/ietf/meeting/tests_views.py
--- a/ietf/meeting/tests_views.py
+++ b/ietf/meeting/tests_views.py
@@ -4505,10 +4505,11 @@ def do_interim_send_announcement_test(self, base_session=False, extra_session=Fa
             if sess:
                 timeslot = sess.official_timeslotassignment().timeslot
                 self.assertIn(timeslot.time.strftime('%Y-%m-%d'), announcement_text)
-                self.assertIn(
-                    '(%s to %s UTC)' % (
+                self.assertRegex(
+                    announcement_text,
+                    r'(%s\s+to\s+%s\s+UTC)' % (
                         timeslot.utc_start_time().strftime('%H:%M'),timeslot.utc_end_time().strftime('%H:%M')
-                    ), announcement_text)
+                    ))
         # Count number of sessions listed
         if base_session and extra_session:
             expected_session_matches = 3
Repository: ietf-tools/datatracker

Issue:
AD dashboard should also display trend when current == 0
### Description

https://datatracker.ietf.org/doc/ad/ with the trending arrows would benefit by displaying the trend *even* if the current value is 0.

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:
I think it does show it, but only if the count thirty days ago was not also zero (and so the trend is flat anyway). Is there a field where you think something should be displayed?
This may indeed be the case. Then, this issue is not relevant (to be checked of course).

The 30-day period appears a little short to me BTW, should rather be more than 2 telechats
This is lingering - should we turn this into a request to look back more than 30 days instead?
nudge
nudge
> This is lingering - should we turn this into a request to look back more than 30 days instead?

IMHO: yes
How many days?
Like briefly discussed with @rjsparks , 120 days (= IETF cycle) would be a better match ;-)

Resolving patch:
diff --git a/ietf/doc/views_search.py b/ietf/doc/views_search.py
--- a/ietf/doc/views_search.py
+++ b/ietf/doc/views_search.py
@@ -461,7 +461,7 @@ def ad_dashboard_sort_key(doc):
 
 
 def ad_workload(request):
-    delta = datetime.timedelta(days=30)
+    delta = datetime.timedelta(days=120)
     right_now = timezone.now()
 
     ads = []


Test patch:
Repository: ietf-tools/datatracker

Issue:
Verify whether DocumentInfo.order is ever used
If it is not used, remove it.
Verify whether DocumentInfo.order is ever used
If it is not used, remove it.


Discussion:
Having discussed it with you, I'll take this one, Jean.
Having discussed it with you, I'll take this one, Jean.

Resolving patch:
diff --git a/ietf/doc/migrations/0003_remove_document_info_order.py b/ietf/doc/migrations/0003_remove_document_info_order.py
new file mode 100644
--- /dev/null
+++ b/ietf/doc/migrations/0003_remove_document_info_order.py
@@ -0,0 +1,34 @@
+# Copyright The IETF Trust 2023, All Rights Reserved
+from django.db import migrations, models
+
+
+def forward(apps, schema_editor):
+    migrations.RemoveField(
+        model_name='dochistory',
+        name='order',
+    )
+    
+    migrations.RemoveField(
+        model_name='document',
+        name='order',
+    )
+
+def reverse(apps, schema_editor):
+    migrations.AddField(
+        model_name='dochistory',
+        name='order',
+        field = models.IntegerField(default=1, blank=True),
+    )
+
+    migrations.AddField(
+        model_name='document',
+        name='order',
+    )
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ("doc", "0002_auto_20230320_1222"),
+    ]
+
+    operations = [migrations.RunPython(forward, reverse)]
diff --git a/ietf/doc/models.py b/ietf/doc/models.py
--- a/ietf/doc/models.py
+++ b/ietf/doc/models.py
@@ -113,7 +113,6 @@ class DocumentInfo(models.Model):
     pages = models.IntegerField(blank=True, null=True)
     words = models.IntegerField(blank=True, null=True)
     formal_languages = models.ManyToManyField(FormalLanguageName, blank=True, help_text="Formal languages used in document")
-    order = models.IntegerField(default=1, blank=True) # This is probably obviated by SessionPresentaion.order
     intended_std_level = ForeignKey(IntendedStdLevelName, verbose_name="Intended standardization level", blank=True, null=True)
     std_level = ForeignKey(StdLevelName, verbose_name="Standardization level", blank=True, null=True)
     ad = ForeignKey(Person, verbose_name="area director", related_name='ad_%(class)s_set', blank=True, null=True)


Test patch:
Repository: ietf-tools/datatracker

Issue:
Reset password only works for the primary email address
### Describe the issue

Users can login with any email address associated with the account.
But the reset password only looks at the primary email address.
If a user enters a non-primary email address, they get an error: 
> Didn't find a matching account. If you don't have an account yet, you can [create one](https://datatracker.ietf.org/accounts/create/).

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:

Resolving patch:
diff --git a/ietf/ietfauth/views.py b/ietf/ietfauth/views.py
--- a/ietf/ietfauth/views.py
+++ b/ietf/ietfauth/views.py
@@ -463,6 +463,12 @@ def password_reset(request):
             # We still report that the action succeeded, so we're not leaking the existence of user
             # email addresses.
             user = User.objects.filter(username__iexact=submitted_username, person__isnull=False).first()
+            if not user:
+                # try to find user ID from the email address
+                email = Email.objects.filter(address=submitted_username).first()
+                if email and email.person and email.person.user:
+                    user = email.person.user
+
             if user and user.person.email_set.filter(active=True).exists():
                 data = {
                     'username': user.username,


Test patch:
diff --git a/ietf/ietfauth/tests.py b/ietf/ietfauth/tests.py
--- a/ietf/ietfauth/tests.py
+++ b/ietf/ietfauth/tests.py
@@ -563,6 +563,21 @@ def test_reset_password_address_handling(self):
         self.assertIn(active_address, to)
         self.assertNotIn(person.user.username, to)
 
+    def test_reset_password_without_username(self):
+        """Reset password using non-username email address"""
+        url = urlreverse('ietf.ietfauth.views.password_reset')
+        person = PersonFactory()
+        secondary_address = EmailFactory(person=person).address
+        inactive_secondary_address = EmailFactory(person=person, active=False).address
+        empty_outbox()
+        r = self.client.post(url, { 'username': secondary_address})
+        self.assertContains(r, 'We have sent you an email with instructions', status_code=200)
+        self.assertEqual(len(outbox), 1)
+        to = outbox[0].get('To')
+        self.assertIn(person.user.username, to)
+        self.assertIn(secondary_address, to)
+        self.assertNotIn(inactive_secondary_address, to)
+
     def test_review_overview(self):
         review_req = ReviewRequestFactory()
         assignment = ReviewAssignmentFactory(review_request=review_req,reviewer=EmailFactory(person__user__username='reviewer'))
Repository: ietf-tools/datatracker

Issue:
View WGs in a given area from the area group view.
### Description

From an area group view, [such as for ART](https://datatracker.ietf.org/group/art/about/), it would be nice to be able to view all WGs in that group. This is visible at [the list of all WGs](https://datatracker.ietf.org/wg/#art), but this requires going through the list of all WGs.

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)


Discussion:

Resolving patch:
diff --git a/ietf/group/views.py b/ietf/group/views.py
--- a/ietf/group/views.py
+++ b/ietf/group/views.py
@@ -544,6 +544,7 @@ def group_about(request, acronym, group_type=None):
     can_provide_update = can_provide_status_update(request.user, group)
     status_update = group.latest_event(type="status_update")
 
+    subgroups = Group.objects.filter(parent=group, state="active").exclude(type__slug__in=["sdo", "individ", "nomcom"]).order_by("type", "acronym")
 
     return render(request, 'group/group_about.html',
                   construct_group_menu_context(request, group, "about", group_type, {
@@ -556,6 +557,7 @@ def group_about(request, acronym, group_type=None):
                       "charter_submit_url": charter_submit_url,
                       "editable_roles": group.used_roles or group.features.default_used_roles,
                       "closing_note": e,
+                      "subgroups": subgroups,
                   }))
 
 def all_status(request):


Test patch: