Skip to content

2024-08-29 maintainer meeting

types.list

What the heck is up with types.list??

  • The corresponding REST endpoint sometimes takes 5+ seconds to resolve.
  • But the RPC method returns a static blob
  • And that static blob contains a ton of useless currency code data

Do we even need an API for this? Can we hard-code that blob on the front end? And remove the currency codes?

Discussion

  • There were 2 REST endpoint types, DB types and UI types.
  • Front end was only using one, we identified the one we were using (UI types) and migrated it to types.list RPC
  • Yes, types.list just returns a static blob
  • Initially, we were going to return metadata about installed types and allow the UI to dynamically only show the types available on the server.
  • That was never implemented.
  • Ideally, we’d do this, but it’s not a priority for beta.
  • DB types are not yet implemented, but it was a list of types in the SQLAlchemy engine.
    • All Postgres types except for Mathesar custom types.
  • Blob is not worth filtering dynamically - just data transmission savings.
  • If it’s just a static blob, we don’t need an API at all, we can just store it on the frontend.
    • Everyone is fine with this.
  • Will also speed up page loading.
  • Confirmed that types that we don’t have first class support for yet (e.g. CIRCLE) will show correctly as “Other” in the UI.

Conclusion

Move types.list to a static blob in the frontend, remove the API.

Sean will trim the currency codes.

Users changing their own privileges

What should we do about user being able to change their own privileges?

  • For the RC, do we display the owner in the ‘Granted privileges’ section in the permissions modals?
  • We cannot fully prevent the user from changing their own privileges since the ownership could be inherited, but can be partially prevented by not showing the owning role in the privileges list.
  • What should we do after RC?

Discussion

  • The team reviewed the current UI.
  • We’re fine with not showing the owner in the privileges list for RC.
  • We should figure out a better solution for the beta, let’s add to our “design added” list.
  • Owner role may not have the privileges to actually delete the item.
    • We don’t show the privileges the owner has anywhere.
    • Consider doing this?

Default privileges

We need to be able to display, set, and update default privileges for an object as it applies to all roles.

  • Users would be able to perform operations on the object even though their roles are not displayed in the permissions modal.
  • Do we need this for the RC?

Discussion

  • We don’t display default privileges anywhere in the UI, it would be nice to do.
  • Not an RC blocker, but let’s track in our “design needed” list for beta.

Roles: Member vs Usage

In the roles page, we display all members for a role. However, only members with USAGE access can actually use the parent role without having to explicitly make a SET ROLE query.

  • Should we show all members on the roles page? (I think we should show them but differentiate them).
  • In all other places where we show child roles (in the permissions modals), we ought to only show members with USAGE.
  • How do we differentiate between members with and without USAGE.
  • Do we need to worry about this for the RC?

Discussion

  • Roles can be inherited in two ways:
    • Using INHERIT - user gets privileges inherited without switching roles, these roles have USAGE
    • Using INHERIT FALSE - user needs to switch roles explicitly to use the role
      • We don’t have a way to do this through our UI right now.
  • For RC, we can only show the roles that use INHERIT TRUE / INHERIT.
  • For beta, we should show both and figure out how to explain the distinction between the two.
  • How do we handle adding child roles via our UI?
    • We grant with INHERIT
    • We need to make this explicit somehow.
  • What is the use case for this feature?
    • e.g. Multitenancy, role per client, explicit role switch means that information can’t be leaked.
  • We could not make any changes for the RC, just explain this is a limitation.
  • For now, only show roles with INHERIT TRUE everywhere, including on the permissions modal.

Conclusion

  • Only show roles with usage (INHERIT TRUE) in the UI anywhere we show child roles.
  • Track the larger UX issue (differentiate between different types of child roles) as a design issue for beta
  • Pavish to make the necessary GitHub issues and Basecamp tasks for beta

roles.delete complications

Since roles are a server level concept in Postgres, a single role can own/have privileges on objects across multiple databases.

  • To drop a role “X” in postgres, we are first required to reassign ownership of all the DB objects owned by the role “X” another role “Y”.
  • This reassignment needs to happen over every database on the database server which we might not have access to.
  • This could make it impossible for us to drop a role if a role owns objects across databases we may have access to.
  • How should Mathesar handle these situations?

Discussion

  • What kind of error should we show for this?
    • For now, we can just show the same error we get from Postgres.
    • Error message says something like: ‘This role has dependent objects’
    • Posgres returns all the objects owned by the role, not just the first one, so we can also display them if we’d like to.
  • No need to track further work.
    • We can put more effort into better error messages if users give us feedback.

Visual/UX Improvements PR

How to best submit visual improvements work for review? Here’s the draft PR.

Discussion

  • Should further work be committed to the same PR or kept separate?
  • Logical separation between PR: table inspector vs. modal improvements
  • Separate PRs are probably easier to review.
  • Rather than attaching a private document, add all information / rationale / guidelines directly to the PR description.
    • More visible to the community, context all in one place.
  • Review process should involve one frontend engineer (for code) and Kriti (for visual review)
  • Ghislaine should double check that changes to common components don’t cause visual issues in other places that the component is used.

Permissions UX comments

Some new minor comments on permissions UX Figma document, do we need to discuss them?

Discussion

  • Comments are related to the icon, copy, and role indicator consistency.
  • Can Pavish implement the most up-to-date version (after comments are resolved), or would that slow things down?
    • It won’t slow things down, Pavish will implement.
  • No need to discuss the feedback here, we’ll discuss async on Figma.