Hi, I’m Yemisi. This is my first contribution and I’m trying to setup. Currently running the test using ./runtests.py command and I’m getting this error
" from django.utils.deprecation import (
ImportError: cannot import name ‘RemovedInDjango51Warning’ from 'django.utils.deprecation"
The above error is coming from runtests module complaining of import error
Hi,
Based on my experience with the same error, I think this might be because of conflicting versions.
Have you just downloaded a local copy of Django? If yes, make sure you install
it in a virtual environment. Once you do, don’t forget to activate the virtual environment.
After ensuring only one django version is installed in my venv, now I’m getting this error
import django
ModuleNotFoundError: No module named ‘django’
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File “./runtests.py”, line 19, in
raise RuntimeError(
RuntimeError: Django module not found, reference tests/README.rst for instructions.
The error suggests that Django isn’t installed. Are you following Unit tests | Django documentation | Django ?
Yes i followed the documentation. I’ve been able to fix it, thank you.
@carltongibson as a new contributor who picked a ticket to work on,after setting my virtual environment and running the unittest for the cloned project,I want to ask these questions:
if I’m to work on a ticket (either implementing new feature or fixing a bug), am i to reproduce and work on the ticket in another project outside the cloned django project? I mean ( “django admin startproject” kind of project ) or work inside the django project that i cloned?
Does it mean to reproduce, i am to validate the existence of the bug or fix the problem?
Hey Yemisi it sounds like you’re making progress!
You can reproduce the issue either way. Ideally you can add a test to the Django test suite that shows the issue. Sometimes it’s hard to do that so you can create a test project with startproject to recreate the issue in. (Make sure you have your development venv active for this.) — Neither is the right answer here: it depends. (I’m constantly creating mini test projects.)
Yes, reproduce, means to recreate the issue to show that it is valid. (Sometimes it doesn’t reproduce, which can mean it’s not valid.) Once you’re able to reproduce the issue it makes it feasible to see where it’s coming from, write a test case, and fix it.
HTH.
@carltongibson I’m Working on a ticket, “Admin Foreign Key widgets don’t quote keys”. When I trIied to reproduce the bug, I realized that the widgets quote characters and numbers as the value of the primary key.
The challenge I have is that the widgets don’t quote keys of primary key value that is a number and the unicode of the number is a special character. E.g, let’s assume the primary key value is 4000, and I try to click on the ‘change’ icon in the Admin site, I get the error that ID “@00” doesn’t exist. Perhaps it was deleted? The unicode of 40 is “@”. but when I click on the unicode of 4000 without "" as the prefix, I don’t get the error. This usually happens with the number has a unicode of special character.
Can you suggest an idea on how I can go about this?
There was a mistake in the second paragraph. Below is the corrected one,
The challenge I have is that the widgets don’t quote keys of primary key value that is a number and the unicode of the number is a special character. E.g, let’s assume the primary key value is "_4000 ", and I try to click on the ‘change’ icon in the Admin site, I get the error that ID “@00” doesn’t exist. Perhaps it was deleted?
The unicode of 40 is “@”. but when I click on the unicode of 4000 without “_” as the prefix, I don’t get the error. This usually happens with the number has a unicode of special character.
Do you have a branch you push to GitHub so we can see the code?
Can you link to the ticket?
Can you link to the code in question in Django on GitHub?
(It’s not easy to see where you’re at from just the description.)
The admin has quoting utilities, which I’m guessing need to be used here.
Test cases from sample keys to expected results will be handy.
(But all is much easier to see in a draft pull request usually 
I reproduced the bug in another project, outside the cloned django project that I have. Can I send the link to the repository here?
Yes, great!
… or even better — if you have a test project reproducing the issue, you can comment with that on the Trac ticket.
If your project has a README with the steps needed to see the issue in action clearly, that’s perfect, as it lets others get to the heart of it quickly, so they can understand it and help you.
Here is the link to the ticket #30386 (Admin foreign key widgets don't quote keys.) – Django
This is the link to the Github Repository
Hi @Oluwayhemisi that looks great. I’ll give it a run in the morning.
If you added a paragraph or two at the end of the Readme saying where you’re stuck, or what your question is (that above yes?) that would be worthwhile too.
Hi @Oluwayhemisi — so the next step here is to look at the original PR and the example in the test project @felixxm uploaded to the ticket and see if you can improve the proposed solution.
Converting Mariusz’ into an extra test case for the Django test suite would be a good step. (Taking the original PR, adding the new test case, and having that fail would be the status at that point — the fix would then make it pass)
I will have another look in more depth early next week.
Thank you @carltongibson I now have a better understanding of what to do with the information you provided above.
@carltongibson I used the quote function from Django.contrib.admin.utils to test,
which I implemented this test case to check the quoted primary key in the rendered HTML form
def test_foreign_key_raw_id_widget_renders_quoted_pk_in_change_url(self):
house = House.objects.create(name='?a=b')
rel = Room._meta.get_field('house').remote_field
w = widgets.ForeignKeyRawIdWidget(rel, widget_admin_site)
# apply quote function to primary key value
pk_quoted = quote(str(house.pk))
# render the widget
rendered = w.render('test', house.pk, attrs={})
# check that the primary key is properly quoted in the rendered HTML
self.assertIn(f'href="/admin_widgets/house/{pk_quoted}/change/"', rendered)
I also downloaded the file Mariusz was talking about and try to add a pizza based on the issue he raised and I also saved it which worked from my end. I don’t know if there’s more to the issue that was raised
Hi @Oluwayhemisi — please open a PR on GitHub with the changes you think should be applied, and the additional test case here. I can review then properly. (Without running the code it’s impossible to say 
)
I don’t know if there’s more to the issue that was raised
It may be that it can be resolved. Or else we can add an extra test case to your PR, which we can then fix.
Thanks!
Thank you so much, I will open a PR on GitHub with the changes
Please I’m having issue pushing to github, I’m having this error :
The current branch #30386_admin_foreignkey has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin #30386_admin_foreignkey