project-search: add identifer to search field

[vellip]

Describe your changes
include filtering bplans by identifier in project search/kiezradar

fixes #6207

Tasks

• PR name contains story or task reference
• Steps to recreate and test the changes
• Documentation (docs and inline)
• Tests (including n+1 and django_assert_num_queries where applicable)
• Changelog

[m4ra]

bplan is a project, so the attribute identifier can be checked directly. this will fix the tests too.
see inline comments.

[m4ra]

this should be project.indentifier, since bplan is externalproject and externaprojects are projects. And I see you pass bplans directly in your tests, which makes sense.

[vellip]

@m4ra I tried this before and again today but it didn't work. Since ExternalProject and Projects are not abstract models but just further inherited, they don't have that identifier field on themselves, I can only access that through the Bplan model. And to get that I have to follow the OneToOne relation that is being created when a model inherits another model, which I do in the code here and in serializers.py.

[vellip]

If I try to just return project.identifier I get nothing back. And doing type(instance) also shows that it's a Project not a Bplan, doing vars(instance) also shows no identifier.

[m4ra]

Indeed, for this to work we need to query projects = Project.objects.select_related("externalproject__bplan").all(). This would decrease the amount of queries. And then we can squash the three checks into one with if hasattr(p, 'externalproject') and hasattr(p.externalproject, 'bplan'): Need to find where we query the projects.

[vellip]

Maybe I am missing something, but since get_search_profiles_for_project does not query the project, it would mean whoever is using get_search_profiles_for_project would have to always query with the select_related, otherwise it would lead to bugs. I imagine it's any easy thing to oversee and don't know if we should change that.

I could query the project again, something like

project = Project.object.select_related("externalproject__bplan").get(pk=project.filter)

but I suppose that feels weird as well. In the serializer it might be easier because we can just override get_queryset in all the views where it's used, but still I am not sure if this works that well? What do you think?

[m4ra]

The new field method identifier in the project serializers, it is introducing more lookups when we call it from other views, e.g the list of projects. That's why we are getting a test failure related to caching. So yes It is not related to the get_serch_profiles_for_project. Can you add the externalproject__bplan here? I just tested it locally and the caching test is passing.
ps. I realized am commenting on the wrong place, it should be in the serializers o_O

[m4ra]

same here, just check for if hasattr(project.identifier) and the currently failing task will pass fine.

can you add the field in the bplan tests as well?