Ash support

[Flo0807]

This issue contains work that needs to be done to provide basic Ash support in Backpex. We really appreciate contributions to further integrate Ash into Backpex. In case you want to tackle some issues related to enhancing Ash support, it is useful to discuss details with us in advance. You can just message us on Slack or open a new discussion. Then we can make things concrete, discuss implementation details and create a dedicated (sub) issue for your feature.

The goal of this issue is to provide a broad roadmap for Ash support. We want to keep implementation details in separate issues so as not to overcomplicate this one.

Note that some sections still have numerous questions and uncertainties, so you may also want to help us specify how to implement certain things. None of this is set in stone. You might also have additional stuff that needs to be included in this issue.

General

Primary Keys

We use the primary key of a resource and its value for several things in Backpex. Currently, users cannot use a compound key because the primary key value is used in the URL to identify resources. You also need to configure the primary key explicitly in the live resource configuration. Ash allows us to pull the primary key from the resource.

• Pull primary key from the resource in case of Ash
• Support compound keys (might not be in scope of Ash)

PubSub and Notifications

Currently, we just use PubSub to notify changes to resources. Ash comes with Notifierst hat are called for each action that occurs on a resource. We have to link our notification / pub sub logic with Ash.

• Link Backpex publishing logic with Ash Notifiers

Improve Backpex.Adapters.Ash and Backpex.Resource

The aim is to improve the Ash Adapter and to implement at least the same functionality as the Ecto Adapter.

• get
  • basic implementation
  • make read action configurable and pass input and options to it (see below)
• list / read
  • basic implementation
  • make read action configurable and pass input and options to it (see below)
  • make pagination and ordering work
• count
  • basic implementation
  • we need to take search and filters into account
  • we can’t assume that any given resource’s data layer supports counting a query
• delete_all / destroy
  • basic implementation
  • make destroy action configurable and pass input and options to it (see below)
• insert / create
  • basic implementation
  • make create action configurable and pass input and options to it (see below)
• update
  • use update_all in update action
• update_all
  • basic implementation
  • make update action configurable and pass input and options to it (see below)

Support other actions than defaults

• Ash: Support other actions than defaults #825

Authorization

While we may have already solved some authorization issues by being able to provide options like the actor for all Ash actions, there is still some work to be done.

Backpex provides a can?/3 function to disallow certain actions. This can also be used to hide actions. Ash also provides a can/3 function that can be used to check if a user can perform an action.

We might also rethink authorization with Backpex in general.

• Rethink authorization in Backpex
• In case of ash, use their can/3 function to check if a user can perform an action and hide / disallow these actions in Backpex (e.g., deleting items)

Handle errors

We need to handle errors properly. Ash comes with additional and domain-specific errors compared to Ecto. This is especially relevant for the resource module (Backpex.Resource) and adapter functions. We may need to create another abstraction layer for errors (because we even have more adapters in the future)

Filters

Filters are tied directly to Ecto. Currently, you define a query callback to filter items. We have to find a way to abstract filters in a way that they can be used in different adapters. We might delegate to adapter specific functions that have to be implemented by users.

For your interest: We want to improve filters in general by validating them with a schemaless changeset (We might kill two birds with one stone)

Metrics

Metrics like Filters are tied directly to Ecto. Currently, you define a query callback to filter items for a metric.

• Delegate metrics filtering to adapter specific functions that have to be implemented by users

Resource and Item Actions

Currently, we use the same live component and markup for resource forms (edit and new), as well as for resource action and item action forms. We want to decouple the resource and item action logic from the resource form logic. This will improve code quality and make it easier to support edit and new forms for Ash resources.

• Decouple resource and item actions from resource forms

We plan to continue validating item and resource action forms with Ecto and use Ecto schemaless changesets for them in the future (even with full ash integration).

Fields

Some of our fields are tied to Ecto. For example, the Backpex.Fields.BelongsTo contains logic for querying options with Ecto. We need to move all Ecto specific logic out of fields so that they can be used, regardless of what adapter is being used. We might abstract some field logic to achieve this goal. In the first step, it might not be possible to move every piece of code that is related to Ecto (for example, Ecto specific field options, like select). We might just raise an error if this code is being used with the Ash adapter. An additional goal is to use every field in our demo in ash resources.

• Backpex.Fields.Boolean
• Backpex.Fields.BelongsTo
  • Raise error when options_query field option is used with Ash adapter
• Backpex.Fields.Currency
• Backpex.Fields.Date
• Backpex.Fields.DateTime
• Backpex.Fields.HasMany
• (Backpex.Fields.HasManyThrough)
  • should not be done now (will be refactored completely)
• Backpex.Fields.InlineCRUD
• Backpex.Fields.MultiSelect
• Backpex.Fields.Number
• Backpex.Fields.Select
• Backpex.Fields.Text
• Backpex.Fields.Textarea
• Backpex.Fields.Time
• Backpex.Fields.URL
• Backpex.Fields.Upload

Ecto specific field options

• Raise an error if select options is being used with the Ash adapter

Edit and new forms with Ash

Currently, Edit and new (resource) forms cannot be used with Ash. We need to discuss whether to keep and reuse the current implementation or use AshPhoenix.Form in case the Ash adapter is used. Maintaining different implementations (per adapter) could be a lot of work. We need to carefully consider how to approach this.