Feedback
Roadmap
Changelog

Have something to say?

Tell us how we could make the product more useful to you.

In Progress

Sync list of tables

Currently the list of tables for a given profile is static until the user goes to refresh the connection. Additionally we only keep the list of tables a user has scanned/queried. This has a few issues: The tables could go stale. If a table has been deleted, we don’t clean it up, we leave it in the ui today. New tables require going through the table discovery process again. We need to automagically refresh the list of tables for connected profiles&regions whenever the app is connected. That way we can discover new tables, and discard old ones.

Orlando Adeyemi 3 months ago

Syncing edit states

Background In Dynomate, there are currently two ways to edit an item: Quick Edit (context menu) Triggered from the row’s context menu. Edits are applied immediately to DynamoDB (no staging). Inline / JSON Editor (sidebar) Editing directly in the table cell or in the JSON sidebar. Edits are staged and must be explicitly confirmed as part of a 2-step process before being written to DynamoDB. Problem If a user: Makes an inline/JSON edit to an item → edit becomes staged. Then performs a Quick Edit on the same item (instead of confirming the staged change), The original staged operations remain in the “pending” state, even though the underlying item has changed. This leads to: Stale staged operations that don’t match the current item in the table. Potentially dangerous writes if the user later confirms a staged edit that was created against an out-of-date version of the item. Confusing UX: the staged badge / count suggests there are valid pending changes, but the table is showing newer data. We need the staged operations to stay in sync with the state of the table, and to be automatically refreshed or cancelled when they become stale. Desired Behavior / High-Level Requirements Staged operations sync with table refreshes/updates Whenever the table data is refreshed (manual refresh, batch operations, re-query, pagination change, filter change, or background refresh), Dynomate should: Reconcile staged operations against the latest item data. Cancel or mark as invalid any staged operations that no longer match the item’s current state. Quick Edit should reconcile staged edits If a Quick Edit is performed on an item that has existing staged edits: Either: (Preferred) Automatically cancel the staged edits for that item, or Surface a clear UX state (“Staged edits invalidated due to newer changes”) and remove them from the “to be applied” batch. The user should never be able to accidentally confirm an edit that was staged before a newer Quick Edit.

Orlando Adeyemi 3 months ago

Completed

Table scan -> Query

Using a onetable, i’ll have composite keys, pk: `organisation#orgid123#location#locId123` sk: `department#asdf#someOtherKey` I’m lazy and waste table IO, so I scan, I then want to use the pk and sk to query the table, if I copy the pk and select Query, paste, then come back and copy the sk, back to query, the previously pasted pk is gone. I want some nice way to pick the pk in a scan or record, and say, use in a Query….

James Leech 9 months ago

2

Completed

Support for IAM users + MFA + STS temporary creds workflow.

When a profile with a role_arn specifies a source_profile, the app should automagically trigger MFA login. Sample profile below: [profile mfa-src] mfa_serial = arn:aws:iam::112928:mfa/google-auth region = ap-southeast-2 output = json [profile mfa-secura-dynamodb] role_arn = arn:aws:iam::1123:role/MFAAdministratorAccess source_profile = mfa-src region = ap-southeast-2

Dynomate 11 months ago

1