django-councilmatic
django-councilmatic copied to clipboard
make friendly event slugs that aren't legistar-specific
Ref: https://github.com/datamade/django-councilmatic/blob/master/councilmatic_core/management/commands/loaddata.py#L744-L751
Any suggestions on how best to remove this? Should I remove wholesale, or hide it behind some logic where we check if the url is legistar? I believe source is a required field for pupa scrapes, so there should always be something here -- my gut is that we should just remove it?
looks like the real issue here isn't the existence of warnings, but rather, using legistar ids for the event slug: https://github.com/datamade/django-councilmatic/blob/master/councilmatic_core/management/commands/loaddata.py#L804
if we wana remove all legistar-specific stuff from django-councilmatic, we should discuss how we want to make the event slug. should we generate something friendly like we do for bills/people (perhaps from event name + date/time), or should we go the lazy route & just use the event ocd id (like we're already doing when there isn't a legistar id)? cc @fgregg
Ah gotcha. I'm fine with ocd id, but I'll admit I prefer stripping the ocd-event bit in favour of hex uuid portion :)
But for something more semantic, we could opt for "
EDIT: Again, I'm a-ok with an url from the ocd id for simplicity for now :)
@cathydeng I like the idea of human readable slugs, with fallback to ocd-id hex for clashing slugs.
mkay, let's go with that
an additional bit of complexity: we'll also have to handle redirecting existing event urls (that use the legistar id as a slug) in chi-councilmatic & nyc-councilmatic. similar code here: https://github.com/datamade/chi-councilmatic/blob/c9cf2b5e2b7a2897f54faf7678f69fc20735e6ff/chicago/views.py#L82-L90
woo. can we just add slug col to event table in a migration and assume the db will be blown away and loaddata re-run?
EDIT: Oh hey, already a slug field ;)