internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: bookwyrm-social/bookwyrm

Issue:
Clarify UI around content warnings
A few problems with content warnings:
 - [ ] The button is icon-only and hard to find for visual users in the compose UI (I think it's fine for screen reader users):
<img width="360" alt="Screen Shot 2021-09-18 at 11 11 48 AM" src="https://user-images.githubusercontent.com/1807695/133898456-ec77f0d2-febd-428f-aa70-4702e8576d31.png">

 - [x] ~When content warnings are active in the compose box, they aren't clearly labeled (again, for visual users only):~ (fixed by #1422)
<img width="357" alt="Screen Shot 2021-09-18 at 11 12 44 AM" src="https://user-images.githubusercontent.com/1807695/133898461-71879dc4-7a69-4280-a33f-7607746b8454.png">

- [x] #1430
<img width="779" alt="Screen Shot 2021-09-18 at 11 13 09 AM" src="https://user-images.githubusercontent.com/1807695/133898481-c63000d9-1ffd-4742-89ec-8e0558921c30.png">



Discussion:

Resolving patch:
diff --git a/bookwyrm/views/status.py b/bookwyrm/views/status.py
--- a/bookwyrm/views/status.py
+++ b/bookwyrm/views/status.py
@@ -85,9 +85,7 @@ def post(self, request, status_type, existing_status_id=None):
         if hasattr(status, "quote"):
             status.raw_quote = status.quote
 
-        if not status.sensitive and status.content_warning:
-            # the cw text field remains populated when you click "remove"
-            status.content_warning = None
+        status.sensitive = status.content_warning not in [None, ""]
         status.save(broadcast=False)
 
         # inspect the text for user tags


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Celery is only using low priority queue
I'm not sure if this is happening for everyone or just bookwyrm.social, but all my celery tasks are going to the `low_priority` queue and it's making everything run super slowly!

(@tofuwabohu are you noticing this in flower?)


Discussion:
This seems to be working in dev and not production

Resolving patch:
diff --git a/celerywyrm/settings.py b/celerywyrm/settings.py
--- a/celerywyrm/settings.py
+++ b/celerywyrm/settings.py
@@ -13,6 +13,7 @@
 CELERY_RESULT_BACKEND = f"redis://:{REDIS_BROKER_PASSWORD}@{REDIS_BROKER_HOST}:{REDIS_BROKER_PORT}/{REDIS_BROKER_DB_INDEX}"
 
 CELERY_DEFAULT_QUEUE = "low_priority"
+CELERY_CREATE_MISSING_QUEUES = True
 
 CELERY_ACCEPT_CONTENT = ["json"]
 CELERY_TASK_SERIALIZER = "json"


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
updating progress doesn't work
Warning : i see this bug as unlinked with instance, because i saw it on my instance and on bookwyrm.social. 

When i go to the book view, i have a block with two progress, but without any print of the pages i've read. 
![bookwyrm1](https://user-images.githubusercontent.com/40766799/156523379-53341dc3-cb0a-4213-989b-e62ec0cd4b38.png)

If i want to edit the progress to add pages number read, i have the choice between two dates and the number input. So i fill in the form. with only page number filled.
![bookwyrm2](https://user-images.githubusercontent.com/40766799/156523381-37a613ff-bcad-4bd3-81c2-b9667b77c4c9.png)

Then i'm going back to the book view, but with 3 entries instead of two. page number hasn't been saved/printed and it added a new progress instead of editing it.
![bookwyrm3](https://user-images.githubusercontent.com/40766799/156523383-ed2789cb-d6b5-4d04-ae59-c5f65ff82625.png)

One problem is you can't save a progress without a comment, but even with that fix, i think progress should indicate the pages read and the pages left to be read. a more "graphic' layout could be very cool ;)


Discussion:

Resolving patch:
diff --git a/bookwyrm/forms/forms.py b/bookwyrm/forms/forms.py
--- a/bookwyrm/forms/forms.py
+++ b/bookwyrm/forms/forms.py
@@ -45,7 +45,7 @@ class Meta:
 
 class ReadThroughForm(CustomForm):
     def clean(self):
-        """make sure the email isn't in use by a registered user"""
+        """don't let readthroughs end before they start"""
         cleaned_data = super().clean()
         start_date = cleaned_data.get("start_date")
         finish_date = cleaned_data.get("finish_date")


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
should be able to see logged-in user's following/followers
**Describe the bug**
if i click on the following users (https://ziurkes.group.lt/user/athinkingmeat/following) - i get 403 page, which is not expected. i would expect to see my own following/follower users.

**To Reproduce**
Steps to reproduce the behavior:
just click on following/followers on logged-in user's profile page

**Expected behavior**
should see a list of following users

**Screenshots**
<img width="552" alt="image" src="https://user-images.githubusercontent.com/81133/169102523-1891c406-aab5-485f-9c9b-d9caa9ca3c6f.png">

**Instance**
https://ziurkes.group.lt




Discussion:

Resolving patch:
diff --git a/bookwyrm/views/user.py b/bookwyrm/views/user.py
--- a/bookwyrm/views/user.py
+++ b/bookwyrm/views/user.py
@@ -106,7 +106,7 @@ def get(self, request, username):
         if is_api_request(request):
             return ActivitypubResponse(user.to_followers_activity(**request.GET))
 
-        if user.hide_follows:
+        if user.hide_follows and user != request.user:
             raise PermissionDenied()
 
         followers = annotate_if_follows(request.user, user.followers)
@@ -129,7 +129,7 @@ def get(self, request, username):
         if is_api_request(request):
             return ActivitypubResponse(user.to_following_activity(**request.GET))
 
-        if user.hide_follows:
+        if user.hide_follows and user != request.user:
             raise PermissionDenied()
 
         following = annotate_if_follows(request.user, user.following)


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Follow Request bug: looks as if you already follow a person if you go to profile of requester
When an account with moderated follows has a follow request incoming the following happens:

You see a notification about someone wanting to follow you. You go to their profile to see what they are like and... it looks like you already follow this person? Because the "Follow" button erroneously reads "Unfollow". 

Additionally, there is no other indication of a pending follow request while on their profile.

**To Reproduce**

1. Set your account to prompt follow requests
2. Get a follow request
3. Go to the profile of the requester
4. The follow button now reads "Unfollow", implying you follow them already (you don't)

As seen on bookwyrm.social

(anyway thanks for this excellent network of book nerds mouse!!)



Discussion:

Resolving patch:
diff --git a/bookwyrm/models/relationship.py b/bookwyrm/models/relationship.py
--- a/bookwyrm/models/relationship.py
+++ b/bookwyrm/models/relationship.py
@@ -218,7 +218,7 @@ def clear_cache(user_subject, user_object):
     """clear relationship cache"""
     cache.delete_many(
         [
-            f"relationship-{user_subject.id}-{user_object.id}",
-            f"relationship-{user_object.id}-{user_subject.id}",
+            f"cached-relationship-{user_subject.id}-{user_object.id}",
+            f"cached-relationship-{user_object.id}-{user_subject.id}",
         ]
     )
diff --git a/bookwyrm/templatetags/interaction.py b/bookwyrm/templatetags/interaction.py
--- a/bookwyrm/templatetags/interaction.py
+++ b/bookwyrm/templatetags/interaction.py
@@ -42,7 +42,7 @@ def get_relationship(context, user_object):
     """caches the relationship between the logged in user and another user"""
     user = context["request"].user
     return get_or_set(
-        f"relationship-{user.id}-{user_object.id}",
+        f"cached-relationship-{user.id}-{user_object.id}",
         get_relationship_name,
         user,
         user_object,
@@ -61,6 +61,6 @@ def get_relationship_name(user, user_object):
         types["is_blocked"] = True
     elif user_object in user.following.all():
         types["is_following"] = True
-    elif user_object in user.follower_requests.all():
+    elif user in user_object.follower_requests.all():
         types["is_follow_pending"] = True
     return types


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
403 when eating book
When I try to rate this book 3 stars, I’m getting a 403 forbidden page. 

https://bookwyrm.social/book/102478/s/machines-like-me

I’m attempting to rate it publicly and I’m signed in. 


Discussion:

Resolving patch:
diff --git a/bookwyrm/models/status.py b/bookwyrm/models/status.py
--- a/bookwyrm/models/status.py
+++ b/bookwyrm/models/status.py
@@ -218,7 +218,8 @@ def raise_not_editable(self, viewer):
         """certain types of status aren't editable"""
         # first, the standard raise
         super().raise_not_editable(viewer)
-        if isinstance(self, (GeneratedNote, ReviewRating)):
+        # if it's an edit (not a create) you can only edit content statuses
+        if self.id and isinstance(self, (GeneratedNote, ReviewRating)):
             raise PermissionDenied()
 
     @classmethod


Test patch:
diff --git a/bookwyrm/tests/views/test_status.py b/bookwyrm/tests/views/test_status.py
--- a/bookwyrm/tests/views/test_status.py
+++ b/bookwyrm/tests/views/test_status.py
@@ -76,6 +76,28 @@ def test_create_status_comment(self, *_):
         self.assertEqual(status.book, self.book)
         self.assertIsNone(status.edited_date)
 
+    def test_create_status_rating(self, *_):
+        """create a status"""
+        view = views.CreateStatus.as_view()
+        form = forms.RatingForm(
+            {
+                "user": self.local_user.id,
+                "rating": 4,
+                "book": self.book.id,
+                "privacy": "public",
+            }
+        )
+        request = self.factory.post("", form.data)
+        request.user = self.local_user
+
+        view(request, "rating")
+
+        status = models.ReviewRating.objects.get()
+        self.assertEqual(status.user, self.local_user)
+        self.assertEqual(status.book, self.book)
+        self.assertEqual(status.rating, 4.0)
+        self.assertIsNone(status.edited_date)
+
     def test_create_status_wrong_user(self, *_):
         """You can't compose statuses for someone else"""
         view = views.CreateStatus.as_view()
Repository: bookwyrm-social/bookwyrm

Issue:
Logged out view of list of lists is empty
This is a 🤦 on my part -- it should directly query the list of public lists, instead of trying to use the redis cache, which relies on logged in users


Discussion:

Resolving patch:
diff --git a/bookwyrm/views/list/lists.py b/bookwyrm/views/list/lists.py
--- a/bookwyrm/views/list/lists.py
+++ b/bookwyrm/views/list/lists.py
@@ -17,7 +17,10 @@ class Lists(View):
 
     def get(self, request):
         """display a book list"""
-        lists = ListsStream().get_list_stream(request.user)
+        if request.user.is_authenticated:
+            lists = ListsStream().get_list_stream(request.user)
+        else:
+            lists = models.List.objects.filter(privacy="public")
         paginated = Paginator(lists, 12)
         data = {
             "lists": paginated.get_page(request.GET.get("page")),


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Cannot respond to follow request.
### Discussed in https://github.com/bookwyrm-social/bookwyrm/discussions/2233

<div type='discussions-op-text'>

<sup>Originally posted by **nerdteacher** July 17, 2022</sup>
![image](https://user-images.githubusercontent.com/77229429/179404826-ba84bff8-cc6f-41dc-aae3-4fffbdf03d8f.png)

I have this follow request that I cannot respond to, but it always leads to this page (regardless of if I hit "accept" or "deny"). It always goes to this page:

![image](https://user-images.githubusercontent.com/77229429/179404878-af57c5b6-006c-4313-ae84-847b8a52caea.png)

I'm not sure if others have had this issue (I did try searching around) or what might be causing it (e.g., if they decided to cancel their request? not sure). I just can't make it go away, haha.</div>


Discussion:
Oh! Sorry for putting it in the wrong place, haha.

Also, I tried searching for the user, and they don't seem to exist (though I can see other people on bookrastinating). So I wonder if it's a result of deleted accounts? Or something of that nature. (Just in case my observations help?)
Oh, if the user is deleted that might explain it -- but it definitely should give you clearer feedback than this
I have a similar issue right now: I sent a follow request from my usual fedi account to my bookwyrm account but it keeps not showing up. If I search for my main account on bookworm, it finds other users from my main instance, but not my profile itself.

Resolving patch:
diff --git a/bookwyrm/models/user.py b/bookwyrm/models/user.py
--- a/bookwyrm/models/user.py
+++ b/bookwyrm/models/user.py
@@ -174,6 +174,11 @@ class User(OrderedCollectionPageMixin, AbstractUser):
     property_fields = [("following_link", "following")]
     field_tracker = FieldTracker(fields=["name", "avatar"])
 
+    @property
+    def active_follower_requests(self):
+        """Follow requests from active users"""
+        return self.follower_requests.filter(is_active=True)
+
     @property
     def confirmation_link(self):
         """helper for generating confirmation links"""


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Adding a space after typing a username will not show that user in the search results
**Describe the bug**
When I search for "@user@example.com" it won't work if the input has a space at the end ("@user@example.com ")
It may work if the user has already been searched for before though. 

**To Reproduce**
Steps to reproduce the behavior:
1. search a user you don't currently follow
2. add a space at the end
3. the user won't be found

**Expected behavior**
spaces should be ignored when looking for usernames

**Instance**
On which BookWyrm instance did you encounter this problem.

**Additional context**
Bookrastinating.com

---

**Desktop**
    - OS: Fedora
    - Browser Firefox
    - Version 102




Discussion:

Resolving patch:
diff --git a/bookwyrm/views/search.py b/bookwyrm/views/search.py
--- a/bookwyrm/views/search.py
+++ b/bookwyrm/views/search.py
@@ -90,6 +90,7 @@ def user_search(request):
     """cool kids members only user search"""
     viewer = request.user
     query = request.GET.get("q")
+    query = query.strip()
     data = {"type": "user", "query": query}
     # logged out viewers can't search users
     if not viewer.is_authenticated:


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Normalize stored ISNI
The `ISNI` field should always be in the same format (without spaces), but right now sometimes the field is stored with spaces between the digits. There should be validation when the author is saved that cleans this value, similar to how ISBNs are validated


Discussion:

Resolving patch:
diff --git a/bookwyrm/models/author.py b/bookwyrm/models/author.py
--- a/bookwyrm/models/author.py
+++ b/bookwyrm/models/author.py
@@ -42,6 +42,11 @@ def save(self, *args, **kwargs):
                 for book in self.book_set.values_list("id", flat=True)
             ]
             cache.delete_many(cache_keys)
+
+        # normalize isni format
+        if self.isni:
+            self.isni = re.sub(r"\s", "", self.isni)
+
         return super().save(*args, **kwargs)
 
     @property


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
books from 2 authors on one author page
**Describe the bug**
The [author page for Travis Baldree](https://bookwyrm.social/author/29528/s/travis-baldree) has books of 2 authors on it, Travis Baldree (expected) and Will Wight (unexpected).

**To Reproduce**
Steps to reproduce the behavior:
1. Go to <https://bookwyrm.social/author/29528/s/travis-baldree>
2. See error

**Expected behavior**
Only books from Travis Baldree.

**Screenshots**
![grafik](https://user-images.githubusercontent.com/3681516/194160493-53ea77d5-ae37-40f6-829d-e06a9b6c9746.png)

**Instance**
bookwyrm.social


Discussion:
This is happening because one of the editions of the books _does_ have Travis Baldree as an author (for example, https://bookwyrm.social/book/205919/s/of-dawn-and-darkness), but it's showing the default edition of that book, which doesn't have that author.

I think the fix here is that the author page should show the edition of the work that has the author if the default edition doesn't -- I'll have to take a look at how I grab the book list and see how straightforward a tweak that is.

Resolving patch:
diff --git a/bookwyrm/models/book.py b/bookwyrm/models/book.py
--- a/bookwyrm/models/book.py
+++ b/bookwyrm/models/book.py
@@ -241,6 +241,10 @@ def default_edition(self):
         """in case the default edition is not set"""
         return self.editions.order_by("-edition_rank").first()
 
+    def author_edition(self, author):
+        """in case the default edition doesn't have the required author"""
+        return self.editions.filter(authors=author).order_by("-edition_rank").first()
+
     def to_edition_list(self, **kwargs):
         """an ordered collection of editions"""
         return self.to_ordered_collection(
diff --git a/bookwyrm/templatetags/book_display_tags.py b/bookwyrm/templatetags/book_display_tags.py
--- a/bookwyrm/templatetags/book_display_tags.py
+++ b/bookwyrm/templatetags/book_display_tags.py
@@ -20,3 +20,9 @@ def get_book_description(book):
 def get_book_file_links(book):
     """links for a book"""
     return book.file_links.filter(domain__status="approved")
+
+
+@register.filter(name="author_edition")
+def get_author_edition(book, author):
+    """default edition for a book on the author page"""
+    return book.author_edition(author)


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Larger, extendable, or configurable character limit for invite request text response
**Is your feature request related to a problem? Please describe.**
When requesting an invite, some users complain that 50 characters is not enough to answer the question. In our case the question is "How do your interests overlap with the concept of Solarpunk?"

**Describe the solution you'd like**
I would like one of the following, if possible:
- Configurable length for the invite request response in the settings form
- Longer length (100-150 would probably suffice)
- Selection of type of response (short versus long text,  this is how Funkwhale does it)

**Describe alternatives you've considered**
Cannot think of an alternative other than patching the code.

**Additional context**
Here is Funkwhale's solution to this problem:
![image](https://user-images.githubusercontent.com/287339/202022345-93a741a3-717d-4961-ad34-da2906285fed.png)



Discussion:
The simplest fix would just be to [expand the character limit in the database](https://github.com/bookwyrm-social/bookwyrm/blob/main/bookwyrm/models/site.py#L184) to something more sensible. 

Resolving patch:
diff --git a/bookwyrm/migrations/0165_alter_inviterequest_answer.py b/bookwyrm/migrations/0165_alter_inviterequest_answer.py
new file mode 100644
--- /dev/null
+++ b/bookwyrm/migrations/0165_alter_inviterequest_answer.py
@@ -0,0 +1,18 @@
+# Generated by Django 3.2.16 on 2022-11-15 22:43
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ("bookwyrm", "0164_status_ready"),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name="inviterequest",
+            name="answer",
+            field=models.TextField(blank=True, max_length=255, null=True),
+        ),
+    ]
diff --git a/bookwyrm/models/site.py b/bookwyrm/models/site.py
--- a/bookwyrm/models/site.py
+++ b/bookwyrm/models/site.py
@@ -181,7 +181,7 @@ class InviteRequest(BookWyrmModel):
     invite = models.ForeignKey(
         SiteInvite, on_delete=models.SET_NULL, null=True, blank=True
     )
-    answer = models.TextField(max_length=50, unique=False, null=True, blank=True)
+    answer = models.TextField(max_length=255, unique=False, null=True, blank=True)
     invite_sent = models.BooleanField(default=False)
     ignored = models.BooleanField(default=False)
 


Test patch:
Repository: bookwyrm-social/bookwyrm

Issue:
Running behind a proxy produces wrong embedding URLs
I was a little bit confused that the URLs for embedding were http instead of https. After looking up where that comes from 

https://github.com/bookwyrm-social/bookwyrm/blob/fdc477afdf4002ea432741121024ea75dbc68192/bookwyrm/views/list/list.py#L53

`build_absolute_uri()` will always generate an absolute URI with the same scheme the current request has - as the traffic comes via http vfrom the proxy it will always build http://URL. 

Iw as confused as my proxy is giving the correct headers in the request. I learned that Django needs to be configured to believe the headers. This is done by adding `SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')` to `settings.py`

You can read about it here: https://docs.djangoproject.com/en/3.2/ref/settings/#secure-proxy-ssl-header

**As this can be a security issue I would not recommend to add it to `settings.py` per default but I recommend to add an option into .env that this can be set there and stays after an update.** 

I have it at the moment in my `settings.py` and I am prepared to put it back there every time - but I am waiting for the update I forget it and get confused. 

As my setup is forwarding _every_ requests to https it is no problem if someone would take the `http`-ULR by accident. I know Servers which do not forward to `https:` by default and sometimes admins do not care as port 80 its just serving nothing. 

Who knows what is coming in the future. I saw the first servers who do not have a port 80 any more - even no forwarding. I think it is just a question of time until we see more and more SSL only Setups.

Long talking short: Please take it into consideration. 




Discussion:

Resolving patch:
diff --git a/bookwyrm/settings.py b/bookwyrm/settings.py
--- a/bookwyrm/settings.py
+++ b/bookwyrm/settings.py
@@ -364,3 +364,7 @@
 OTEL_SERVICE_NAME = env("OTEL_SERVICE_NAME", None)
 
 TWO_FACTOR_LOGIN_MAX_SECONDS = 60
+
+HTTP_X_FORWARDED_PROTO = env.bool("SECURE_PROXY_SSL_HEADER", False)
+if HTTP_X_FORWARDED_PROTO:
+    SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")


Test patch: