enterprise/backend · 0a20cd02e837d89a170c9b9661c259cce32ae60e · Engineering Digital Service / Metabase · GitLab

Snippets Groups Projects

Audit Queries fall back to email when first/last names are nil (#23393)

adam-james authored 2 years ago

* Audit Queries fall back to email when first/last names are nil

The audit page displays user information, and one column is "Name". Since we now allow nil first/last names, this
value can return as a single space character. Instead, I've changed `common/user-full-name` to fall back to returning
the user's email address if they have no first/last name values.

Additionally:
- since names can be nil, I've added sort by email to some of the queries for the audit page
- display names have been changed from "Name" to "Member" in several queries to better fit the fallback to email

* Add a test to check that audit pages have proper name fallback

* Try to get test passing in CI

* Make query work in MySQL by coalescing 'null' to empty string

0a20cd02

0a20cd02 2 years ago

Code owners

Assign users and groups as approvers for specific file changes. Learn more.

Name	Last commit	Last update
..
src/metabase_enterprise
test/metabase_enterprise
README.md

EE Code Structure Notes

EE namespaces follow the pattern work like this.

EE namespace = take the equivalent OSS namespace and replace metabase. with metabase-enterprise.<feature> where <feature> is the premium token feature that one must have to use this feature.

For example, Sandboxing-related API endpoints for Tables go in metabase-enterprise.sandboxes.api.table and Sandboxing-related models (e.g. GTAP) go in metabase-enterprise.sandboxes.models. Sandboxing-specific code for existing models follow this same pattern, e.g. Sandboxing-specific code for Tables goes in metabase-enterprise.sandboxes.models.table.

Groups of API routes should be defined in namespaces like we do in OSS, for example metabase-enterprise.content-management.api.review for ModerationReview-related endpoints. All endpoints for a specific feature are combined into a single routes handler in a metabase-enterprise.<feature>.api.routes namespace similar to how OSS routes are combined in metabase.api.routes. Finally, all EE routes are combined into a single handler in metabase-enterprise.api.routes; this handler is included in metabase.api.routes/routes if EE code is available.

Please keep these rules in mind when adding new EE namespaces. In general, new namespaces SHOULD NOT be added directly under metabase-enterprise unless they apply to the Enterprise codebase as a whole; put them under the appropriate metabase-enterprise.<feature> directory instead.

Naming EE API routes

To make things consistent EE-only API routes should follow the same pattern and be given route names that correspond to their namespaces (i.e., are prefixed with ee/<feature>). For example, an :advanced-config-only route to delete User subscriptions should be named something like

DELETE /api/ee/advanced-config/user/:id/subscriptions

rather than

DELETE /api/user/:id/subscriptions

Not all EE endpoints follow this pattern yet, but they should; please feel free to fix stuff as you come across it if I don't get to it first.

Questions ⁉️

Ping me (@cam) if you have any questions.