Beacon Configuration Admin View, with CRUD and Regenerate and Revoke Tokens Actions#585
Beacon Configuration Admin View, with CRUD and Regenerate and Revoke Tokens Actions#585FionaLMcLaren wants to merge 24 commits intomainfrom
Conversation
…-api-keys - Removed old beacon migration that conflicted with device migrations - Updated BeaconsController to use Beacons::Creator service for API key generation - Changed beacon relationships from direct provider/tags to many-to-many beacon_providers and beacon_topics - Updated forms to use provider_ids and topic_ids multi-selects instead of single provider_id and tag_ids - Updated show page to display API key (when just created) instead of token - Updated index page to show region, language, provider count, and topic count - Removed beacon_tag model and references as we now use beacon_topics - Changed status from online/offline to active/revoked based on revoked_at timestamp
Topics use 'title' column, not 'name'. Updated controller and views to use Topic.active.order(:title)
- Update API key display messaging for admin context - Add regenerate_key action in BeaconsController using KeyRegenerator service - Add 'Regenerate API Key' button on show page with confirmation dialog - Full API key still shown only after creation/regeneration via flash - Clearer messaging that full key is displayed immediately after provisioning
- Added document_count method to Beacon model to count available topics - Added file_count method to count actual attached document files - Updated show page with 4 stat cards: Status, Available Topics, Document Files, and Configured Filters - Logic respects beacon's language, providers (or region if no providers), and topic filters
Resolves #572 Adds actions to revoke and regenerate tokens. Refactors the previous "regenerate" code in the controller to be in a model TODO: - Controller specs for beacons controller - Route for revoking a Token
dbac880 to
ca83796
Compare
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- Add libffi-dev package to Dockerfile.dev for Alpine Linux to support ffi gem (dependency).
Allows Bundler to resolve dependencies for Darwin 25.
Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sean Marcia <seanmarcia@github.com>
2071a2e to
3954d6e
Compare
|
Hey @FionaLMcLaren for a ticket with so many visual elements, it's really helpful to put some screenshots in the PR description, particularly for:
Thanks! Solid work! |
devjona
left a comment
There was a problem hiding this comment.
Solid work! I left a few comments.
dmitrytrager
left a comment
There was a problem hiding this comment.
have some comments, mostly about code validation and data integrity
9931cda to
a628a77
Compare
a628a77 to
a24368c
Compare
81601e1 to
8dd9f8e
Compare
cd9ea07 to
2464541
Compare
|
@FionaLMcLaren thanks for providing screenshots! Please let us know when it's ready for review. |
e2867e3 to
4cc78e3
Compare
4cc78e3 to
c595113
Compare
|
@devjona This is ready for review! 🫶 |
| flash[:notice] = "API key has been successfully regenerated. API Key: #{api_key}" | ||
| redirect_to @beacon | ||
|
|
||
| rescue => e |
There was a problem hiding this comment.
Do you expect specific exceptions here? If yes, it is better to specify exception types, like RecordNotFound for example
There was a problem hiding this comment.
I'm not sure if a specific exception is expected here, as the Beacons::KeyRegenerator does not have any explicit error cases itself?
There was a problem hiding this comment.
I think we can take a look at what kinds of errors to expect from the KeyRegenerator but I'm fine with capturing e for now.
This is a good opportunity to make small improvements to the KeyRegenerator spec and add some cases for error handling.
| <div class="form-grid-full" data-controller="select-tags" data-select-tags-dropdown-parent-value="body"> | ||
| <%= form.label :topic_ids, "Topics", class: "form-label" %> | ||
| <%= form.select :topic_ids, | ||
| options_from_collection_for_select(@topics, :id, :title, beacon.topic_ids), |
There was a problem hiding this comment.
Do you need help with this part?
* Move Javascript logic for copying API key from view to its own stimulus controller, `beacons_controller` * Have full API key appear for copying on beacon creation or when the key is regenerated * New `Beacon` helper for status string display logic * Other refactors
| module BeaconsHelper | ||
| def status_string(beacon) | ||
| beacon.revoked? ? "Revoked" : "Active" | ||
| end | ||
| end |
There was a problem hiding this comment.
Minor, but I think this could go on the Beacon model:
def status_string
beacon.revoked? ? "Revoked" : "Active"
endand from the template:
<p class="text-2xl font-bold m-0 mt-2 <%= @beacon.revoked? ? 'text-red-600' : 'text-green-600' %>">
<%= @beacon.status_string %>
</p>If it was more complex logic, then yeah, we could use another file, etc.
This is a nit pick, doesn't need to hold up the ticket.
| export default class extends Controller { | ||
| static targets = ["button", "beaconApiKey"] | ||
|
|
||
| copyApiKey() { |
There was a problem hiding this comment.
I'm not sure this copy functionality is working (tried locally).
There was a problem hiding this comment.
We could add to a later ticket, but the user can still see the API Key and manually select, copy.
What Issue Does This PR Cover, If Any?
Resolves #572
What Changed? And Why Did It Change?
This PR adds the actions to revoke and regenerate tokens. It refactors the previous
"regenerate" code in the controller to be in a model. These actions are accessible to an admin user on their Admin Dashboard, when viewing a Beacon. This PR also does some cleanup on the views here, e.g.: removing the flashes for
:api_key, as the information is already included in the success flashHow Has This Been Tested?
RSpec
Please Provide Screenshots