internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: dj-stripe/dj-stripe

Issue:
Code examples are lost during docs build
eg compare

https://dj-stripe.readthedocs.io/en/master/usage/manually_syncing_with_stripe.html

with

https://github.com/dj-stripe/dj-stripe/blob/master/docs/usage/manually_syncing_with_stripe.rst

from https://github.com/dj-stripe/dj-stripe/issues/1147#issuecomment-622605047


Discussion:

Resolving patch:
diff --git a/djstripe/migrations/0005_2_2.py b/djstripe/migrations/0005_2_2.py
--- a/djstripe/migrations/0005_2_2.py
+++ b/djstripe/migrations/0005_2_2.py
@@ -97,7 +97,7 @@ class Migration(migrations.Migration):
             name="customer_phone",
             field=models.TextField(
                 blank=True,
-                help_text="The customer’s phone number. Until the invoice is finalized, this field will equal customer.phone_. Once the invoice is finalized, this field will no longer be updated.",
+                help_text="The customer’s phone number. Until the invoice is finalized, this field will equal customer.phone. Once the invoice is finalized, this field will no longer be updated.",
                 max_length=5000,
             ),
         ),
@@ -518,7 +518,7 @@ class Migration(migrations.Migration):
                     "customer_phone",
                     models.TextField(
                         blank=True,
-                        help_text="The customer’s phone number. Until the invoice is finalized, this field will equal customer.phone_. Once the invoice is finalized, this field will no longer be updated.",
+                        help_text="The customer’s phone number. Until the invoice is finalized, this field will equal customer.phone. Once the invoice is finalized, this field will no longer be updated.",
                         max_length=5000,
                     ),
                 ),
diff --git a/djstripe/models/billing.py b/djstripe/models/billing.py
--- a/djstripe/models/billing.py
+++ b/djstripe/models/billing.py
@@ -319,7 +319,7 @@ class BaseInvoice(StripeModel):
         max_length=5000,
         blank=True,
         help_text="The customer’s phone number. Until the invoice is finalized, "
-        "this field will equal customer.phone_. Once the invoice is finalized, "
+        "this field will equal customer.phone. Once the invoice is finalized, "
         "this field will no longer be updated.",
     )
     customer_shipping = JSONField(


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
Creating account fails when request to `api.stripe.com/v1/account` is missing `payouts_enabled`
For a reason I have not yet been able to nail down, my response from `https://api.stripe.com/v1/account` is missing the `payouts_enabled` field.  This causes the eventual `create_from_stripe_object` call to fail with an `IntegrityError` because `Account.payouts_enabled` is not nullable.

I'll open a PR to make this field nullable, but am very open to arguments against and alternate handling!


Discussion:
Hi, is this from a webhook or from doing an API request and passing the result to sync_from_stripe_data on the result?

What is your dashboard stripe API version?  ie the default version shown in developers at https://dashboard.stripe.com/

It'd be helpful if you filled in the sync issue template, since this sounds like a sync issue (eg copy-paste https://github.com/dj-stripe/dj-stripe/issues/new?assignees=&labels=webhook+%2F+sync+issues&template=issue-with-webhooks-or-sync.md&title= to here)

Hi @therefromhere, thanks for the questions!

Under the hood, I think you're right that it's a webhook passing data to sync_from_stripe_data, so I'll be happy to move it over.

The specific issue results from `djstripe.models.Account.get_default_account()` making a request to `/v1/accounts` and then kwargsing that data into `djstripe.models.Account._create_from_stripe_object()`.  Because the response from `/v1/accounts` does not include the `payouts_enabled` key.  Because `djstripe.models.Account.payouts_enabled` is non-nullable , it causes an integrity error.

Our default dash api version is `2018-02-28`, but the client is using `2019-12-03`.

Still sound to you like I should move this over to a sync issue?


Resolving patch:
diff --git a/djstripe/migrations/0007_account_payouts_enabled_nullable.py b/djstripe/migrations/0007_account_payouts_enabled_nullable.py
new file mode 100644
--- /dev/null
+++ b/djstripe/migrations/0007_account_payouts_enabled_nullable.py
@@ -0,0 +1,20 @@
+# Generated by Django 3.0.5 on 2020-05-03 01:45
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ("djstripe", "0006_2_3"),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name="account",
+            name="payouts_enabled",
+            field=models.BooleanField(
+                help_text="Whether Stripe can send payouts to this account", null=True
+            ),
+        ),
+    ]
diff --git a/djstripe/models/connect.py b/djstripe/models/connect.py
--- a/djstripe/models/connect.py
+++ b/djstripe/models/connect.py
@@ -79,7 +79,7 @@ class Account(StripeModel):
         ),
     )
     payouts_enabled = models.BooleanField(
-        help_text="Whether Stripe can send payouts to this account"
+        null=True, help_text="Whether Stripe can send payouts to this account"
     )
     product_description = models.CharField(
         max_length=255,


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
Issue when attempting to sync tiered Price Model in 2.4.2
**Describe the bug**

It looks like 9bd896ffd944e809b95abae884a2149dc8a79f27 introduced a regression when trying to sync a tiered Price model. Probably Price is not the only model affected.

Check out this trace:

```
$ ./manage.py djstripe_sync_models Price
Syncing Price:
INFO     stripe.log_info:64- message='Request to Stripe api' method=get path=https://api.stripe.com/v1/prices?expand[0]=data.tiers
INFO     stripe.log_info:64- message='Stripe API response' path=https://api.stripe.com/v1/prices?expand[0]=data.tiers response_code=200
  id=price_1IFltoFz0jfFqjGsm5fbXWt5, pk=6 (xxx)
  id=price_1IFe29Fz0jfFqjGsTpBrPQql, pk=1 (xxx)
  id=price_1IFe29Fz0jfFqjGslZM7rvu1, pk=2 (xxx)
  id=price_1IFe28Fz0jfFqjGsM0SIOAa6, pk=3 (xxx)
  id=price_1IFe27Fz0jfFqjGsEN4c0MxR, pk=4 (xxx)
  id=price_1IFe23Fz0jfFqjGsbFrlPDSi, pk=5 (xxx)
INFO     stripe.log_info:64- message='Request to Stripe api' method=get path=https://api.stripe.com/v1/prices
INFO     stripe.log_info:64- message='Stripe API response' path=https://api.stripe.com/v1/prices response_code=200
  id=price_1IFltoFz0jfFqjGsm5fbXWt5, pk=6 (xxx)
  id=price_1IFe29Fz0jfFqjGsTpBrPQql, pk=1 (xxx)
  id=price_1IFe29Fz0jfFqjGslZM7rvu1, pk=2 (xxx)
  id=price_1IFe28Fz0jfFqjGsM0SIOAa6, pk=3 (xxx)
  id=price_1IFe27Fz0jfFqjGsEN4c0MxR, pk=4 (xxx)
  id=price_1IFe23Fz0jfFqjGsbFrlPDSi, pk=5 (xxx)
  Synced 12 Price
```

The Price objects are synced twice. The first time with the tiers attribute expanded and the second time without expanding it and overwriting it, so the final object doesn't include tiers.

**Software versions**
- dj-stripe version: 2.4.2
- Python version: 3.7
- Django version: 3.0.11
- Stripe API version: 2.55
- Database type and version: postgresql 10.10

**Steps To Reproduce**

1. Create tiered Price and add tiers in Stripe Dashboard
2. Sync Price models with manage command

**Can you reproduce the issue with the latest version of master?**

Yes, both 2.4.2 and master are affected (2.4.1 is not affected)

**Expected Behavior**

The Price Model should have the tiers JSONField object populated.


Discussion:

Resolving patch:
diff --git a/djstripe/management/commands/djstripe_sync_models.py b/djstripe/management/commands/djstripe_sync_models.py
--- a/djstripe/management/commands/djstripe_sync_models.py
+++ b/djstripe/management/commands/djstripe_sync_models.py
@@ -140,7 +140,7 @@ def get_list_kwargs(self, model):
                     for subscription in models.Subscription.api_list()
                 )
             )
-        else:
+        elif not all_list_kwargs:
             all_list_kwargs.append({})
 
         return all_list_kwargs


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
get error while modifying the paymentintent
usage = instance.update(sid=instance.id,amount=200)


stripe.error.AuthenticationError: No API key provided. (HINT: set your API key using "stripe.api_key = <API-KEY>"). You can generate API keys from the Stripe web interface.  See https://stripe.com/api for details, or email support@stripe.com if you have any questions.


Discussion:
any workaround please???
@Javedgouri what are you using for your api key settings in your django settings file? (be sure to redact info)
@kavdev 
STRIPE_LIVE_PUBLIC_KEY = get_secret('STRIPE_LIVE_PUBLIC_KEY')
STRIPE_LIVE_SECRET_KEY = get_secret('STRIPE_LIVE_SECRET_KEY')
STRIPE_TEST_PUBLIC_KEY = get_secret('STRIPE_TEST_PUBLIC_KEY')
STRIPE_TEST_SECRET_KEY = get_secret('STRIPE_TEST_SECRET_KEY')
STRIPE_LIVE_MODE = False  # Change to True in production
DJSTRIPE_WEBHOOK_SECRET = get_secret('DJSTRIPE_WEBHOOK_SECRET') 

It works while creating payment intent but give error while calling modify function.
@Javedgouri ah okay. It's been a while since I've dug into the api, but you might be missing an ``api_key`` argument to ``.update()``. What object is ``instance`` an instance of?
@Javedgouri what is the `instance` object? a PaymentIntent object?

I don't really know why we have an `update()` method on PaymentIntent actually… it's a shorthand for `.api_retrieve().modify(…)`, seems very unnecessary especially since it's the only model (other than Invoice) to have an update() method.

Resolving patch:
diff --git a/djstripe/models/core.py b/djstripe/models/core.py
--- a/djstripe/models/core.py
+++ b/djstripe/models/core.py
@@ -1648,8 +1648,8 @@ def update(self, api_key=None, **kwargs):
         :type api_key: string
         """
         api_key = api_key or self.default_api_key
-
-        return self.api_retrieve(api_key=api_key).modify(**kwargs)
+        response = self.api_retrieve(api_key=api_key)
+        return response.modify(response.stripe_id, api_key=api_key, **kwargs)
 
     def _api_cancel(self, api_key=None, **kwargs):
         """


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
ValidationError in models.Customer.sync_from_stripe_data 
```
stripe_customer = stripe.Customer.create()
djs_customer = djstripe.models.Customer.sync_from_stripe_data(stripe_customer)
```

Gives the following error:
```
ValidationError at /store/subscribe/main/7/
{'currency': ['This field cannot be blank.'], 'subscriber': ['This field cannot be blank.']}
```

**Software versions**
- Dj-Stripe version: 2.5.0
- Python version: 3.8.11
- Django version: 3.2
- Stripe API version: 2.60.0
- Database type and version: PostgreSQL 12



Discussion:

Resolving patch:
diff --git a/djstripe/migrations/0001_initial.py b/djstripe/migrations/0001_initial.py
--- a/djstripe/migrations/0001_initial.py
+++ b/djstripe/migrations/0001_initial.py
@@ -752,6 +752,7 @@ class Migration(migrations.Migration):
                 (
                     "currency",
                     djstripe.fields.StripeCurrencyCodeField(
+                        blank=True,
                         default="",
                         help_text="The currency the customer can be charged in for recurring billing purposes",
                         max_length=3,
@@ -813,6 +814,7 @@ class Migration(migrations.Migration):
                 (
                     "subscriber",
                     models.ForeignKey(
+                        blank=True,
                         null=True,
                         on_delete=django.db.models.deletion.SET_NULL,
                         related_name="djstripe_customers",
diff --git a/djstripe/models/core.py b/djstripe/models/core.py
--- a/djstripe/models/core.py
+++ b/djstripe/models/core.py
@@ -614,6 +614,7 @@ class Customer(StripeModel):
         ),
     )
     currency = StripeCurrencyCodeField(
+        blank=True,
         default="",
         help_text="The currency the customer can be charged in for "
         "recurring billing purposes",
@@ -701,6 +702,7 @@ class Customer(StripeModel):
     # dj-stripe fields
     subscriber = models.ForeignKey(
         djstripe_settings.get_subscriber_model_string(),
+        blank=True,
         null=True,
         on_delete=models.SET_NULL,
         related_name="djstripe_customers",


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
API change for Invoice.billing_reason
It seems to be undocumented ([docs](https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason)) but the [`InvoiceBillingReason`](https://github.com/dj-stripe/dj-stripe/blob/master/djstripe/enums.py#L390) enum is missing the value `automatic_pending_invoice_item_invoice`. Stripe is sending this undocumented value which is causing my webhooks to fail due to the max_length of the `Invoice.billing_reason` field (currently calculates to a max_length=22 due to the missing field).

I propose adding this new enum value to `InvoiceBillingReason`.

Relevant Note: I am using the [`pending_invoice_item_interval`](https://stripe.com/docs/api/subscriptions/object#subscription_object-pending_invoice_item_interval) option when I create subscriptions.


Discussion:

Resolving patch:
diff --git a/djstripe/enums.py b/djstripe/enums.py
--- a/djstripe/enums.py
+++ b/djstripe/enums.py
@@ -395,6 +395,7 @@ class InvoiceBillingReason(Enum):
     manual = _("Manual")
     upcoming = _("Upcoming")
     subscription_threshold = _("Subscription threshold")
+    automatic_pending_invoice_item_invoice = _("Automatic pending invoice item invoice")
 
 
 class InvoiceCollectionMethod(Enum):
diff --git a/djstripe/migrations/0017_auto_20220524_1836.py b/djstripe/migrations/0017_auto_20220524_1836.py
new file mode 100644
--- /dev/null
+++ b/djstripe/migrations/0017_auto_20220524_1836.py
@@ -0,0 +1,25 @@
+# Generated by Django 3.2.13 on 2022-05-24 18:36
+
+from django.db import migrations
+import djstripe.enums
+import djstripe.fields
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('djstripe', '0016_taxcode'),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name='invoice',
+            name='billing_reason',
+            field=djstripe.fields.StripeEnumField(blank=True, default='', enum=djstripe.enums.InvoiceBillingReason, max_length=38),
+        ),
+        migrations.AlterField(
+            model_name='upcominginvoice',
+            name='billing_reason',
+            field=djstripe.fields.StripeEnumField(blank=True, default='', enum=djstripe.enums.InvoiceBillingReason, max_length=38),
+        ),
+    ]


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
Creating WebhooksEndpoint locally raises tolerance constraint failed error
**Describe the bug**
Attempting to create new WebhookEndpoint via django admin fails with `djstripe.models.webhooks.WebhookEndpoint.DoesNotExist: WebhookEndpoint matching query does not exist.`

above error is caused by failure to create local object:

sqlite: `sqlite3.IntegrityError: NOT NULL constraint failed: djstripe_webhookendpoint.tolerance`
mysql: `MySQLdb.IntegrityError: (1048, "Column 'tolerance' cannot be null")`

The WebhookEndpoint is successfully created in stripe, but not in the local DB.

**To Reproduce**
Steps to reproduce the behavior:

1. Fresh django installation with dj-stripe
2. `python3 manage.py migrate && python3 manage.py runserver`
3. Add an API key via Django admin
4. [optionally] run `python3 manage.py djstripe_sync_models`
5. Add a new WebhookEndpoint via django admin

**Expected behavior**
A new WebhookEndpoint is created in local django app

**Environment**
- dj-stripe version: 2.8.1
- stripe API version: "2022-11-15"
- Database: [any]
- Python version: 3.11.4
- Django version: 4.2.3

**Can you reproduce the issue with the latest version of master?**

Yes

It appears that the API does not return the `tolerance` key, so somewhere along the line this field is explicitly set to `None`, which eventually causes the  error `IntegrityError: NOT NULL constraint failed: djstripe_webhookendpoint.tolerance` (as opposed to the default value being used as defined in the model).

This issue can be easily reproduced by modifying the webhook fixture (`tests/fixtures/webhook_endpoint_fake0001.json`) to remove the `tolerance` key, and running pytest.

I'm very new to dj-stripe, but issue can be resolved by adding a check to `models.webhooks.WebhookEndpoint._attach_objects_hook`:

```python
    def _attach_objects_hook(
        self, cls, data, current_ids=None, api_key=djstripe_settings.STRIPE_SECRET_KEY
    ):
        ...
        self.djstripe_uuid = data.get("metadata", {}).get("djstripe_uuid")

        if not isinstance(data.get("tolerance", None), (int, float)):
            self.tolerance = djstripe_settings.WEBHOOK_TOLERANCE
```

If this is actually a bug, and the proposed fix looks good, I'd be happy to contribute a PR.


Discussion:
Had the same problem and this fixed it. +1 

Resolving patch:
diff --git a/djstripe/models/webhooks.py b/djstripe/models/webhooks.py
--- a/djstripe/models/webhooks.py
+++ b/djstripe/models/webhooks.py
@@ -83,6 +83,7 @@ def _attach_objects_hook(
         )
 
         self.djstripe_uuid = data.get("metadata", {}).get("djstripe_uuid")
+        self.tolerance = data.get("tolerance", djstripe_settings.WEBHOOK_TOLERANCE)
 
 
 def _get_version():


Test patch:
Repository: pyca/cryptography

Issue:
Hasher.hexdigest() is documented as returning a str, but returns unicode under python2
It should return a native string under boht py2 and py3



Discussion:
I can't find a function which attempts to return a native string in both py2 and py3 in either the stdlb or six, did nobody ever think this would be a useful thing? I thought all the wsgi trouble would have produced something to this effect at last O_O

`str()`.

You'll have to do `str(bytes.decode("ascii"))`

On Tue, Oct 22, 2013 at 11:59 AM, Donald Stufft notifications@github.comwrote:

> str().
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pyca/cryptography/issues/148#issuecomment-26831487
> .

## 

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


Resolving patch:
diff --git a/cryptography/primitives/hashes.py b/cryptography/primitives/hashes.py
--- a/cryptography/primitives/hashes.py
+++ b/cryptography/primitives/hashes.py
@@ -44,7 +44,7 @@ def digest(self):
                                                self.digest_size)
 
     def hexdigest(self):
-        return binascii.hexlify(self.digest()).decode("ascii")
+        return str(binascii.hexlify(self.digest()).decode("ascii"))
 
     def _copy_ctx(self):
         return self._api.copy_hash_context(self._ctx)


Test patch:
diff --git a/tests/primitives/test_hashes.py b/tests/primitives/test_hashes.py
--- a/tests/primitives/test_hashes.py
+++ b/tests/primitives/test_hashes.py
@@ -28,6 +28,10 @@ def test_base_hash_reject_unicode(self, api):
         with pytest.raises(TypeError):
             m.update(six.u("\u00FC"))
 
+    def test_base_hash_hexdigest_string_type(self, api):
+        m = hashes.SHA1(api=api, data=b"")
+        assert isinstance(m.hexdigest(), str)
+
 
 class TestSHA1(object):
     test_SHA1 = generate_base_hash_test(
Repository: pyca/cryptography

Issue:
Compile error on Debian
Debian's standard OpenSSL appears to not include SSLv2. This was seen in Debian Unstable, but most likely applies to Debian 7.

This is the important bits of the stack trace:

```
cryptography/hazmat/backends/openssl/__pycache__/_cffi__xca198f2bxe6136d81.c: In function ‘_cffi_const_SSL_OP_MSIE_SSLV2_RSA_PADDING’:
cryptography/hazmat/backends/openssl/__pycache__/_cffi__xca198f2bxe6136d81.c:3132:20: error: ‘SSL_OP_MSIE_SSLV2_RSA_PADDING’ undeclared (first use in this function)
```

The full stack trace is available at http://pb.codehash.net/hokahaku .

The output of `openssl version` is `OpenSSL 1.0.1f-dev xx XXX xxxx`.



Discussion:
Also, the Debian Unstable and wheezy `opensslconf.h` have  `OPENSSL_NO_SSL2` defined.


Resolving patch:
diff --git a/cryptography/hazmat/backends/openssl/ssl.py b/cryptography/hazmat/backends/openssl/ssl.py
--- a/cryptography/hazmat/backends/openssl/ssl.py
+++ b/cryptography/hazmat/backends/openssl/ssl.py
@@ -54,7 +54,6 @@
 static const int SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG;
 static const int SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG;
 static const int SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER;
-static const int SSL_OP_MSIE_SSLV2_RSA_PADDING;
 static const int SSL_OP_SSLEAY_080_CLIENT_DH_BUG;
 static const int SSL_OP_TLS_D5_BUG;
 static const int SSL_OP_TLS_BLOCK_PADDING_BUG;


Test patch:
Repository: pyca/cryptography

Issue:
Write release automation software



Discussion:

Resolving patch:
diff --git a/tasks.py b/tasks.py
new file mode 100644
--- /dev/null
+++ b/tasks.py
@@ -0,0 +1,27 @@
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+# implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+from __future__ import absolute_import, division, print_function
+
+import invoke
+
+
+@invoke.task
+def release(version):
+    """
+    ``version`` should be a string like '0.4' or '1.0'.
+    """
+    invoke.run("git tag -s {0}".format(version))
+    invoke.run("git push --tags")
+
+    invoke.run("python setup.py sdist")
+    invoke.run("twine upload -s dist/cryptography-{0}*".format(version))


Test patch:
Repository: pyca/cryptography

Issue:
Use typedef ... *FOO_PTR; where appropriate.
So that FFI knows that the underlying type is opaque but that this is a pointer.

This makes `ffi.typeof` work correctly on bindings where functions take opaque typedef pointers such as some of the `ENGINE_` stuff.

See here for an example of it going wrong https://gist.github.com/public/8456596



Discussion:

Resolving patch:
diff --git a/cryptography/hazmat/bindings/openssl/engine.py b/cryptography/hazmat/bindings/openssl/engine.py
--- a/cryptography/hazmat/bindings/openssl/engine.py
+++ b/cryptography/hazmat/bindings/openssl/engine.py
@@ -24,11 +24,11 @@
 typedef ... DH_METHOD;
 typedef ... RAND_METHOD;
 typedef ... STORE_METHOD;
-typedef ... ENGINE_GEN_INT_FUNC_PTR;
-typedef ... ENGINE_CTRL_FUNC_PTR;
-typedef ... ENGINE_LOAD_KEY_PTR;
-typedef ... ENGINE_CIPHERS_PTR;
-typedef ... ENGINE_DIGESTS_PTR;
+typedef ... *ENGINE_GEN_INT_FUNC_PTR;
+typedef ... *ENGINE_CTRL_FUNC_PTR;
+typedef ... *ENGINE_LOAD_KEY_PTR;
+typedef ... *ENGINE_CIPHERS_PTR;
+typedef ... *ENGINE_DIGESTS_PTR;
 typedef ... ENGINE_CMD_DEFN;
 typedef ... UI_METHOD;
 


Test patch: