feat: person search endpoint#9062
Conversation
| url(r"^person/persons_by_email/$", views_rpc.persons_by_email), | ||
| url(r"^person/(?P<person_id>[0-9]+)/$", views_rpc.rpc_person), | ||
| url(r"^persons/$", views_rpc.rpc_persons), | ||
| url(r"^persons/search/", views_rpc.RpcPersonSearch.as_view()), |
There was a problem hiding this comment.
General question: Isn't Rpc and rpc_ are redundent because these already in views_rpc?
There was a problem hiding this comment.
I think so, but I didn't want to violate the convention we've been using so far in this PR. My inclination is to do a follow-up PR that refactors a bunch of this, including getting rid of the hand-crufted rpcapi.yaml.
These names aren't exposed through the API schema so the impacts both of this being a bad name and of changing the names in a later PR shouldn't impact the purple API client. We should be able to match the existing schema with a generated one, at least pretty closely.
There was a problem hiding this comment.
(Having the prefix in the method/class names is nice if you want to do a from views_rpc import rpc_whatever but I don't think we're likely to do it that way.)
There was a problem hiding this comment.
(not relevant to this PR), should persons_by_email should be rpc_persons_by_email?
What I struggle with is difference between rpc prefixed person and non-rpc prefixed person in views_rpc.
There was a problem hiding this comment.
I guess we weren't as consistent as I thought at a glance. On the datatracker side, there's no such thing as an RpcPerson except where the Rpc is a prefix.
Purple has an RpcPerson model that represents someone who has a role with the RPC - editor, manager, etc.
* improved naming of operation/components in API schema * reused Person schema component * added serializers_rpc.py
Better matches the hand-written schema.
Including ascii / ascii_short might be useful eventually, but since we only show plain_name in the response it can cause confusing results. By the same reasoning we could remove email__address as well, but that's useful and I expect we'll include email addresses in our response soon anyway.
2 participants
This is the datatracker side of ietf-tools/purple#365. Adds a paginated search endpoint for Persons.
I'm conflicted on naming. The names here (
RpcPerson*) follow the pattern we've been using withrpcprefixes, but have the decidedly awful result that the purple view works with something called anRpcPersonthat is not purple'srpc.models.RpcPerson. Suggestions welcome.Note that this is starting to use DRF for the datatracker's purple interface. We have so far only used that for things supporting red. The motivation here is not having to implement custom pagination. The schema changes to
rpcapi.yamlwere done by generating a schema via spectacular and manually pulling in the relevant bits. We will want to make that process better, but I think that's a separate project.