* Add JSON response format to webhooks
Support JSON responses for all webhook endpoints: index, show, create,
update, destroy, and activation. Adds jbuilder views, updates controllers
to use respond_to, and documents the API in docs/API.md.
* Address PR review feedback
- Use distinct board ID in API docs webhook example
- Use render "webhooks/show" in activations controller for consistency
* Address PR review feedback from flavorjones
- Include webhook.board in cache key to avoid stale board data
- Use _url instead of _path for location header consistency
* Fix webhook create test to match Location header format
Use board_webhook_url instead of board_webhook_path since the controller
returns a full URL in the Location header.
* Fix board ID in Location header example in API docs
Use distinct board ID in the Location URL to match the JSON body example.
The webhook activation controller was using account-scoped lookup
instead of board-scoped lookup, allowing users to reactivate webhooks
on boards they don't have access to.
This was an oversight when board-scoping was added to the main webhooks
controller - the activations controller was missed in that update.
The fix adds the BoardScoped concern to properly restrict webhook
activation to boards the user has explicit access to.
In order for model ordering to work as expected in tests, we need to
keep two properties:
- Fixtures are all created in the past
- Models sort in the order that they were created
This allows us to do things like this:
post cards_path, params: { ... }
created_card = Card.last
When using UUIDv7 PKs rather than sequential integers, we have to make
sure a couple of things happen in order for this still to be true:
- Fixtures should generate deterministic IDs that translate to UUIDs
that would have been created in the past (i.e. before today)
- Newly created objects must have enough precision in their timestamps
so that they sort in the order they were created, and their random
component doesn't come into play.
To solve this, we use the deterministic numeric ID as a number of
milliseconds after an early year. And we ensure that the new timestamps
we create have sub-millisecond precision.
These are mainly because the fixture's UUIDs are deterministic rather
than time-sortable, and more places where we need to correct the fixture
IDs as well.
Rob Zolkos