internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: mampfes/hacs_waste_collection_schedule

Issue:
[Bug]: Typo in icon specification: "varient" should be "variant"
### I Have A Problem With:

The integration in general

### What's Your Problem

There is no Material Design Icon with the spelling "varient", it should be "variant".

In the following files:
* `custom_components/waste_collection_schedule/waste_collection_schedule/source/basildon_gov_uk.py`
* `custom_components/waste_collection_schedule/waste_collection_schedule/source/bristol_gov_uk.py`

![image](https://github.com/mampfes/hacs_waste_collection_schedule/assets/394687/8290ce4d-3014-4d0e-a75f-1406030fb20d)


### Source (if relevant)

_No response_

### Logs

_No response_

### Relevant Configuration

_No response_

### Checklist Source Error

- [ ] Use the example parameters for your source (often available in the documentation) (don't forget to restart Home Assistant after changing the configuration)
- [ ] Checked that the website of your service provider is still working
- [ ] Tested my attributes on the service provider website (if possible)
- [X] I have tested with the latest version of the integration (master) (for HACS in the 3 dot menu of the integration click on "Redownload" and choose master as version)

### Checklist Sensor Error

- [ ] Checked in the Home Assistant Calendar tab if the event names match the types names (if types argument is used)

### Required

- [X] I have searched past (closed AND opened) issues to see if this bug has already been reported, and it hasn't been.
- [X] I understand that people give their precious time for free, and thus I've done my very best to make this problem as easy as possible to investigate.


Discussion:

Resolving patch:
diff --git a/custom_components/waste_collection_schedule/waste_collection_schedule/source/basildon_gov_uk.py b/custom_components/waste_collection_schedule/waste_collection_schedule/source/basildon_gov_uk.py
--- a/custom_components/waste_collection_schedule/waste_collection_schedule/source/basildon_gov_uk.py
+++ b/custom_components/waste_collection_schedule/waste_collection_schedule/source/basildon_gov_uk.py
@@ -23,7 +23,7 @@
     "general_waste": "mdi:trash-can",
     "food_waste": "mdi:food",
     "glass_waste": "mdi:bottle-wine",
-    "papercard_waste": "mdi:package-varient",
+    "papercard_waste": "mdi:package-variant",
     "plasticcans_waste": "mdi:bottle-soda-classic",
 }
 NAME_MAP = {
diff --git a/custom_components/waste_collection_schedule/waste_collection_schedule/source/bristol_gov_uk.py b/custom_components/waste_collection_schedule/waste_collection_schedule/source/bristol_gov_uk.py
--- a/custom_components/waste_collection_schedule/waste_collection_schedule/source/bristol_gov_uk.py
+++ b/custom_components/waste_collection_schedule/waste_collection_schedule/source/bristol_gov_uk.py
@@ -27,7 +27,7 @@
     "240L RECYCLING MIXED GLASS": "mdi:bottle-wine",
     "240L RECYCLING PAPER": "mdi:newspaper",
     "1100L GENERAL WASTE": "mdi:trash-can",
-    "1100L RECYCLING CARD": "mdi:package-varient",
+    "1100L RECYCLING CARD": "mdi:package-variant",
     "360L RECYCLING PLASTIC/CANS": "mdi:bottle-soda-classic",
 }
 HEADERS = {


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Dynamic page permissions aren't called on the content model
The documentation mentions a `can_add` method to define on a a custom page model. When this is called in `page_tags.set_page_permissions`, it only calls in on the `Page` instance, never using `Page.get_content_model()`.

I will submit a pull request to fix this, but I'm not sure where the check should go -- is it better in the Page class, having the base `can_add` method delegate to `get_content_model().can_add`, or should it go in the template tag?

Dynamic page permissions aren't called on the content model
The documentation mentions a `can_add` method to define on a a custom page model. When this is called in `page_tags.set_page_permissions`, it only calls in on the `Page` instance, never using `Page.get_content_model()`.

I will submit a pull request to fix this, but I'm not sure where the check should go -- is it better in the Page class, having the base `can_add` method delegate to `get_content_model().can_add`, or should it go in the template tag?



Discussion:
Thanks for picking this up Gavin.

At a glance it looks like it's a regression from this commit: 8fb7c30d8be2119dbefae937b159f9ced615d23c

So the fix probably involves reverting some of that, but not entirely. 

@AlexHill do you remember this and what the fix was? We'll need to take that into account before reverting anything so we don't go around in circles.

Thanks for picking this up Gavin.

At a glance it looks like it's a regression from this commit: 8fb7c30d8be2119dbefae937b159f9ced615d23c

So the fix probably involves reverting some of that, but not entirely. 

@AlexHill do you remember this and what the fix was? We'll need to take that into account before reverting anything so we don't go around in circles.


Resolving patch:
diff --git a/mezzanine/pages/templatetags/pages_tags.py b/mezzanine/pages/templatetags/pages_tags.py
--- a/mezzanine/pages/templatetags/pages_tags.py
+++ b/mezzanine/pages/templatetags/pages_tags.py
@@ -178,6 +178,6 @@ def set_page_permissions(context, token):
     setattr(page, "perms", {})
     for perm_type in ("add", "change", "delete"):
         perm = request.user.has_perm(perm_name % perm_type)
-        perm = perm and getattr(page, "can_%s" % perm_type)(request)
+        perm = perm and getattr(model, "can_%s" % perm_type)(request)
         page.perms[perm_type] = perm
     return ""


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Issue with custom SLUGIFY method
So I try to use slygify from Pytils (https://github.com/j2a/pytils/blob/master/pytils/translit.py#L194 ) like this:

```
SLUGIFY = "pytils.translit.slugify"
```

Every time I save the model that subclasses Displayable I get an error:

```
slugify() got invalid parameter 1 of type NewsItem
```

That's the NewsItem code:

```
from mezzanine.core.fields import RichTextField
from mezzanine.core.models import Displayable
from mezzanine.core.managers import PublishedManager


class NewsItem(Displayable):
    full_text = RichTextField()
    objects = PublishedManager()

    class Meta:
        ordering = ('-publish_date',)

    def __unicode__(self):
        return self.title
```

What could be the problem here?



Discussion:
They use some kind of type checking system that enforces only strings as args:

https://github.com/j2a/pytils/blob/master/pytils/translit.py#L192

I'd suggest just copying their function and putting it into your project.

Yes, but at the same time SLUGIFY = "pytils.translit.slugify" perfectly works on Pages.

Pytils just expect the argument to be basestring, so str or unicode will suffice in that case. The model has a unicode method, so I don't get it, why isn't it working on a custom model...

Page and Displayable both implement a "get_slug" method - Page uses the title, while Displayable uses self.

You could implement get_slug on your custom model the same way Page does.

https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/pages/models.py#L131

Oh, cool. Thanks for help and fast replies.

So what's the perfect way of using custom SLUGIFY on a Displayable model then? Should I reload get_slug() on every custom model? Does it make sense?

We can probably change Displayable to use title instead of self.

Would you like to commit it?

I suppose sure, why not.

Could you please explain then, sorry if that's still a noob question, but, why doesn't Slugged use the self.title for slugify? I mean it has a title field so it could be slugified. No?

Ah I'm sorry for the confusion, I meant Slugged not Displayable.


Resolving patch:
diff --git a/mezzanine/core/models.py b/mezzanine/core/models.py
--- a/mezzanine/core/models.py
+++ b/mezzanine/core/models.py
@@ -91,7 +91,7 @@ def get_slug(self):
         """
         Allows subclasses to implement their own slug creation logic.
         """
-        return slugify(self)
+        return slugify(self.title)
 
     def admin_link(self):
         return "<a href='%s'>%s</a>" % (self.get_absolute_url(),


Test patch:
Repository: stephenmcd/mezzanine

Issue:
% char in fabfile templates causes var substitution to break



Discussion:

Resolving patch:
diff --git a/mezzanine/project_template/fabfile.py b/mezzanine/project_template/fabfile.py
--- a/mezzanine/project_template/fabfile.py
+++ b/mezzanine/project_template/fabfile.py
@@ -1,5 +1,6 @@
 
 import os
+import re
 import sys
 from functools import wraps
 from getpass import getpass, getuser
@@ -212,6 +213,8 @@ def upload_template_and_reload(name):
             remote_data = sudo("cat %s" % remote_path, show=False)
     with open(local_path, "r") as f:
         local_data = f.read()
+        # Escape all non-string-formatting-placeholder occurrences of '%':
+        local_data = re.sub(r"%(?!\(\w+\)s)", "%%", local_data)
         if "%(db_pass)s" in local_data:
             env.db_pass = db_pass()
         local_data %= env


Test patch:
Repository: stephenmcd/mezzanine

Issue:
SuspiciousOperation in asset_proxy URLs
Since switching our site from HTTP to HTTPS, I've been getting the following error on all of TinyMCE's dialog windows.

```
SuspiciousOperation: Attempted access to '/static/grappelli/tinymce/jscripts/tiny_mce/themes/advanced/source_editor.htm' denied.

Stacktrace (most recent call last):

  File "django/core/handlers/base.py", line 115, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
  File "django/contrib/admin/views/decorators.py", line 17, in _checklogin
    return view_func(request, *args, **kwargs)
  File "mezzanine/core/views.py", line 143, in static_proxy
    path = finders.find(url)
  File "django/contrib/staticfiles/finders.py", line 239, in find
    result = finder.find(path, all=all)
  File "django/contrib/staticfiles/finders.py", line 147, in find
    match = self.find_in_app(app, path)
  File "django/contrib/staticfiles/finders.py", line 166, in find_in_app
    if storage.exists(path):
  File "django/core/files/storage.py", line 243, in exists
    return os.path.exists(self.path(name))
  File "django/core/files/storage.py", line 259, in path
    raise SuspiciousOperation("Attempted access to '%s' denied." % name)
```

The URLs that are causing them look like this:

```
https://www.example.com/asset_proxy/?u=https://www.example.com/static/grappelli/tinymce/jscripts/tiny_mce/themes/advanced/source_editor.htm
```



Discussion:
See this thread for some comments:
https://groups.google.com/forum/#!searchin/mezzanine-users/ssl/mezzanine-users/Dr5DXGFtU-w/s-hSNrwk_hQJ

It would be nice if enabling SSL wouldn't screw up the TinyMCE assets, but there's no fix yet as far as I know.
I tried modifying the middleware that generates the asset_proxy urls but it didn't work. I ended up just removing 'admin' from the SSL_FORCE_URL_PREFIXES as I don't really need SSL for the admin pages, just for things like shop checkout and account login.


Resolving patch:
diff --git a/mezzanine/core/views.py b/mezzanine/core/views.py
--- a/mezzanine/core/views.py
+++ b/mezzanine/core/views.py
@@ -135,7 +135,7 @@ def static_proxy(request):
     protocol = "http" if not request.is_secure() else "https"
     host = protocol + "://" + request.get_host()
     generic_host = "//" + request.get_host()
-    for prefix in (host, generic_host, settings.STATIC_URL):
+    for prefix in (settings.STATIC_URL, host, generic_host, '/'):
         if url.startswith(prefix):
             url = url.replace(prefix, "", 1)
     response = ""


Test patch:
Repository: stephenmcd/mezzanine

Issue:
thumbnail template tag doesn't handle url with query parameters
The thumbnail template tag (defined in mezzanine.core.templatetags.mezzanine_tags.py) doesn't properly handle the case where an image URL has query parameters. 

For example, if you're using the S3 backend with django-storages, you can get image urls that look like:

https://mybucket.s3.amazonaws.com/media/foo.png?Signature=Krt5ETtmBIkjW2IL4/k6yXBhoB8=&Expires=1381851766&AWSAccessKeyId=BXDFIXRAKAUR5AIRIW7L

In this case, the thumbnail method will not interpret the filename correctly.



Discussion:

Resolving patch:
diff --git a/mezzanine/core/templatetags/mezzanine_tags.py b/mezzanine/core/templatetags/mezzanine_tags.py
--- a/mezzanine/core/templatetags/mezzanine_tags.py
+++ b/mezzanine/core/templatetags/mezzanine_tags.py
@@ -276,6 +276,9 @@ def thumbnail(image_url, width, height, quality=95):
         return ""
 
     image_url = unquote(unicode(image_url))
+    # Strip query parameters from url, if any
+    if '?' in image_url:
+        image_url = image_url[:image_url.find('?')]
     if image_url.startswith(settings.MEDIA_URL):
         image_url = image_url.replace(settings.MEDIA_URL, "", 1)
     image_dir, image_name = os.path.split(image_url)


Test patch:
Repository: stephenmcd/mezzanine

Issue:
overextends tag broken in Django 1.7+1.8
Looks like the changes made to `loader_tags.py` in a50de50699bb6a24bfb5f118449991aa7608b426 either didn't work or both Django versions have since changed.

As reported here: https://groups.google.com/d/msg/mezzanine-users/_QWfFVB3RVc/ZirizEV9t2YJ

Just pinging @AlexHill as you might have a head's up on this one already. 

I made a quick attempt by changing `find_template_loader = context.engine.find_template_loader` to `find_template_loader = context.engine.find_template_loader` which appears to work for 1.8, but then other possibly unrelated exceptions came up.

BTW my quick tip for actually running `overextends` is to modify the first line of `core/templates/admin/base_site.html` to use it instead of `extends`



Discussion:
I can see a typo there for 1.7: line 62 refers to `django.template.loaders` when it looks like it should refer to `django.template.loader` (as in the code that was deleted). Not sure why that line is being executed under 1.8 at all though, since it should find the method on `context.engine` - certainly possible that there were changes to 1.8 since I wrote that code. Will have a look.


Resolving patch:
diff --git a/mezzanine/template/loader_tags.py b/mezzanine/template/loader_tags.py
--- a/mezzanine/template/loader_tags.py
+++ b/mezzanine/template/loader_tags.py
@@ -49,17 +49,18 @@ def find_template(self, name, context, peeking=False):
         import django.template.loaders.app_directories as app_directories
         try:
             # Django >= 1.8
-            app_template_dirs = app_directories.get_app_template_dirs
+            get_app_template_dirs = app_directories.get_app_template_dirs
+            app_template_dirs = get_app_template_dirs('templates')
         except AttributeError:
             # Django <= 1.7
             app_template_dirs = app_directories.app_template_dirs
 
         try:
             # Django >= 1.8
-            find_template_loader = context.engine.find_template_loader
+            find_template_loader = context.template.engine.find_template_loader
         except AttributeError:
             # Django <= 1.7
-            from django.template.loaders import find_template_loader
+            from django.template.loader import find_template_loader
 
         from mezzanine.conf import settings
 


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Link dialog sometimes won't open in admin interface 
In some situations, trying to open `/displayable_links.js` generates a 500 with the following message:

> TypeError at /displayable_links.js - unorderable types: dict() < dict()

https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/views.py#L197

Replacing this line with e.g. `return HttpResponse(dumps([link[1] for link in sorted(links, key=lambda link: link[1]['title'])]))` fixes the problem.

I'm using Python 3.4, but this line of code looks unintended and shouldn't work on Python 2 either :-)



Discussion:

Resolving patch:
diff --git a/mezzanine/core/views.py b/mezzanine/core/views.py
--- a/mezzanine/core/views.py
+++ b/mezzanine/core/views.py
@@ -194,7 +194,8 @@ def displayable_links_js(request):
             verbose_name = _("Page") if page else obj._meta.verbose_name
             title = "%s: %s" % (verbose_name, title)
         links.append((not page and real, {"title": str(title), "value": url}))
-    return HttpResponse(dumps([link[1] for link in sorted(links)]))
+    sorted_links = sorted(links, key=lambda link: (link[0], link[1]['value']))
+    return HttpResponse(dumps([link[1] for link in sorted_links]))
 
 
 @requires_csrf_token


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Duplicate form fields in admin for user profiles
As discussed here:

https://groups.google.com/forum/#!topic/mezzanine-users/3QmiqfNZjUM



Discussion:
It's probably an issue in mezzanine/accounts/templates/admin/profile_inline.html from what I can tell. 

Possibly:

```
 <div class="items">
      {% for inline_admin_form in inline_admin_formset %}
      <div class="{% if inline_admin_form.original or inline_admin_form.show_url %} has_original{% endif %}">
```

needs something similar to https://github.com/stephenmcd/grappelli-safe/commit/21ba4fac50441cd6825585da9380fe42569ac2db ?

Ok, I think I have it worked out - First, we should add

```
{% if forloop.last %} empty-form{% endif %}
```

within the class part of the div above (as per the grapelli-safe fix) and then add this to admin/global.css:

```
fieldset.profile .items .empty-form {
    display: none;
}
```

I can set up a PR if you like.

Sure, please do.

Fixed in #1450

At this point in time, this change ends up hiding all profile fields, and when I back out this change, only one set of fields are shown - given that, I'll revert it.

With this reverted, I'm still seeing profile fields duplicated in admin, the second set being empty. It's really annoying. My project uses AUTH_PROFILE_MODULE to define the profile fields in my own profile class. I'll override the templates locally to fix this, but I really wish there's a solution that works for everyone.


Resolving patch:
diff --git a/mezzanine/accounts/admin.py b/mezzanine/accounts/admin.py
--- a/mezzanine/accounts/admin.py
+++ b/mezzanine/accounts/admin.py
@@ -51,6 +51,13 @@ class ProfileInline(admin.StackedInline):
         can_delete = False
         template = "admin/profile_inline.html"
         extra = 0
+
+        def get_min_num(self, request, obj=None, **kwargs):
+            """This causes profile forms to be shown when editing but hidden
+            when creating. If min_num is fixed at 1, Django's initial user
+            creation form fails if the profile model has a required field."""
+            return 0 if obj is None else 1
+
     UserProfileAdmin.inlines += (ProfileInline,)
 except ProfileNotConfigured:
     pass


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Incorrectly saving content_model when moving a subclassed Page instance in Pages Change List
The new `set_content_models()` that is being called in a `Page`'s `save()` method is causing all subclassed `Page`s to have `content_model` set to `None`. (link to [commit](https://github.com/stephenmcd/mezzanine/commit/bede76b6f96227350cb0bf0058f555daeb4cc2ad))

Steps to recreate:
A) create a new mezzanine project and add all the initial demo pages
B) login as admin and go to the pages change list
C) Move any page (e.g. Legals) under another page (e.g. Gallery)
D) Open the Legals page.

The page is no longer a RichTextPage, but a regular Page.



Discussion:
I saw that... Do you have any fix?

Reproduced.


Resolving patch:
diff --git a/mezzanine/core/models.py b/mezzanine/core/models.py
--- a/mezzanine/core/models.py
+++ b/mezzanine/core/models.py
@@ -534,10 +534,11 @@ def set_content_model(self):
         Set content_model to the child class's related name, or None if this is
         the base class.
         """
-        is_base_class = (
-            base_concrete_model(ContentTyped, self) == self.__class__)
-        self.content_model = (
-            None if is_base_class else self.get_content_model_name())
+        if not self.content_model:
+            is_base_class = (
+                base_concrete_model(ContentTyped, self) == self.__class__)
+            self.content_model = (
+                None if is_base_class else self.get_content_model_name())
 
     def get_content_model(self):
         """


Test patch:
diff --git a/mezzanine/core/tests.py b/mezzanine/core/tests.py
--- a/mezzanine/core/tests.py
+++ b/mezzanine/core/tests.py
@@ -641,6 +641,24 @@ def test_set_content_model_subclass(self):
         self.assertEqual(page.content_model, 'richtextpage')
         self.assertEqual(page.get_content_model(), richtextpage)
 
+    def test_set_content_model_again(self):
+        """
+        Content model cannot change after initial save.
+
+        That's the only time we'll know for certain that the __class__ is the
+        lowest class in the hierarchy. Of course, content_model will keep
+        getting set to None for base concrete classes, which is confusing but
+        not necessarily a problem.
+        """
+        richtextpage = RichTextPage.objects.create()
+        richtextpage.set_content_model()
+        page = Page.objects.get(pk=richtextpage.pk)
+        self.assertEqual(page.content_model, 'richtextpage')
+        self.assertEqual(page.get_content_model(), richtextpage)
+        page.set_content_model()
+        self.assertEqual(page.content_model, 'richtextpage')
+        self.assertEqual(page.get_content_model(), richtextpage)
+
     def test_contenttyped_admin_redirects(self):
         self.client.login(username=self._username, password=self._password)
Repository: stephenmcd/mezzanine

Issue:
Mezzanine thumbnail templatetag failing to save thumbnails of jpeg images with Pillow >= 4.2.0
Hello,

I've the following environment:

- Mezzanine 4.2.3
- Django 1.10.7
- Python 3.6.1
- Pillow 4.2.1

This version of Mezzanine installed the Pillow above.

Before Pillow 4.2.0, attempting to save an RGBA image as JPEG would discard the alpha channel. From Pillow 3.4.0, a deprecation warning was shown. From Pillow 4.2.0, the deprecation warning is removed and an `IOError` is raised.

This deprecation was discussed on [Pillow Issue 2609](https://github.com/python-pillow/Pillow/issues/2609)

This makes that the thumbnail of jpeg images doesn't be saved.

To fix this, my suggestion is remove the RGB to RGBA conversion on the line [390](https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/templatetags/mezzanine_tags.py#L390) if the image's filetype was JPG or JPEG as follow:

```python
if image.mode not in ("P", "L", "RGBA") and filetype not in ("JPG", "JPEG"):
```

The Alpha channel for JPG/JPEG images is unnecessary since these images doesn't have transparency.


Discussion:

Resolving patch:
diff --git a/mezzanine/core/templatetags/mezzanine_tags.py b/mezzanine/core/templatetags/mezzanine_tags.py
--- a/mezzanine/core/templatetags/mezzanine_tags.py
+++ b/mezzanine/core/templatetags/mezzanine_tags.py
@@ -387,7 +387,8 @@ def thumbnail(image_url, width, height, upscale=True, quality=95, left=.5,
         to_width = from_width * to_height // from_height
     elif to_height == 0:
         to_height = from_height * to_width // from_width
-    if image.mode not in ("P", "L", "RGBA"):
+    if image.mode not in ("P", "L", "RGBA") \
+            and filetype not in ("JPG", "JPEG"):
         try:
             image = image.convert("RGBA")
         except:


Test patch:
Repository: stephenmcd/mezzanine

Issue:
Small typo in mezzanine/core/auth_backends.py
Should read verification rather than verficiation.


Discussion:

Resolving patch:
diff --git a/mezzanine/core/auth_backends.py b/mezzanine/core/auth_backends.py
--- a/mezzanine/core/auth_backends.py
+++ b/mezzanine/core/auth_backends.py
@@ -21,7 +21,7 @@ class MezzanineBackend(ModelBackend):
     For login, is_active is not given, so that the login form can
     raise a specific error for inactive users.
     For password reset, True is given for is_active.
-    For signup verficiation, False is given for is_active.
+    For signup verification, False is given for is_active.
     """
 
     def authenticate(self, *args, **kwargs):


Test patch: