Missing Permissions in DB seed/migration

[shamrickus]

This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

The following permissions are not seeded in the database:

ACME:READ (acme_accounts/providers)
ACME:READ (deliveryservices/sslkeys/generate/acme/)
ACME:READ/CREATE/UPDATE (acme_accounts/)
ACME:READ/DELETE (acme_accounts/{provider}/{email})
ACME:READ (acme_autorenew/)

DBDUMP:READ (dbdump/?)

ROLE:UPDATE/CREATE/DELETE (roles/)

DS-SECURITY-KEY:CREATE/UPDATE/DELETE (deliveryservices/{xmlID}/urisignkeys$,
  deliveryservices/sslkeys/add$,
  deliveryservices/xmlId/{xmlid}/sslkeys$,
  deliveryservices/sslkeys/generate/,
  deliveryservices/xmlId/{name}/urlkeys/copyFromXmlId/{copy-name}/,
  deliveryservices/xmlId/{name}/urlkeys/generate/,
  deliveryservices/xmlId/{name}/urlkeys/,
  deliveryservices/{id}/urlkeys/,
  deliveryservices/sslkeys/generate/letsencrypt/)
  letsencrypt/autorenew/)

PLUGIN:READ (plugins/)

Expected behavior:

At least the admin user should have all of these permissions, potentially other users too.

Steps to reproduce:

Run the db setup and look in the role_capability table and see that these permissions do not exist in there.

[ocket8888]

• CDNI-CAPACITY:UPDATE
• CDNI-CAPACITY:ADMIN
• CDNI-CAPACITY:READ

This didn't already exist when Permissions were updated. Since priv_level still exists and the routes requiring these Permissions ostensibly have a required priv_level that was intentionally set, we can seed these, but that's not strictly necessary, IMO, since that's not something we'd do for a new concept like this once priv_level is removed.

Also I'd vote we rename CDNI-CAPACITY:ADMIN to something like CDNI-CAPACITY:APPROVE-CONFIG to better reflect what it actually does.

[shamrickus]

Edited the issue to reflect. Also removed ssl-key-experation since it's the same story.