I’m extremely pleased to announce Kaffy v0.9.0. This has been the biggest release yet with so many contributions from the community.
The main features in this release:
Introducing extension modules to add custom css and javascript.
Custom form fields for specialized form functionality.
List actions now can have an intermediary step for more input from the user.
Improved layout for mobile screens.
Ability to override Kaffy’s insert, update, and delete functions to customize how Kaffy talks to the repo.
Moved scheduled tasks to their own modules and they have their own option in config.
Ability to customize the query Kaffy uses for the index and show pages.
A more flexible and customizable way to define resources and admin modules.
For a complete list of changes, you can check the repo’s README and CHANGELOG files.
Please note that this is a backwards-incompatible release, but modifications should be quick and minimal.
Many thanks to everyone who contributed in this release.
Oh this is AMAZING – how did I only find out about that now??
I remember having this conversation with a ton of developers - most of them maintain this is not needed, they can write it themselves, it’s a blackbox, etc. etc.
But in my experience, in all webapps you need 1) user management and 2) admin interface. And barely ever are your requrements so specific that they justify rewriting all this from scratch over and over again. Therefore I’ve always been a fan of Python/Django having the admin interface included out of the box. In Ruby/Rails there was ActiveAdmin and one more simiar project, but there have always been some problems with them and they had pretty opinionated ugly design Recently I’ve been a fan of Strapi (built on Koa.js) for quick bootstraping apis (hence the name “stapi”) when prototyping.
What I’m trying to say is thank you, and keep up the great work, it’s worthy!
@aesmail Hey! I am new to Elixir/Phoenix and I am in the process of adding Kaffy to our project. However, I am uncertain of where the admin modules/ widgets logic should live in the application? Could you provide a little more detail?
Notice that admin modules are optional. This means that any code essential to running the project or related to the business logic shouldn’t live there and should live somewhere more appropriate (e.g. context modules).
You could place admin modules anywhere in your application and name them anything you want. However, having them under the same namespace as the schemas gives you the convenience of not having to explicitly list them all in the config file. For example, if you have a user schema (MyApp.Accounts.User) and your admin module is (MyApp.Admins.UserAdmin), you need to tell Kaffy where the admin module for the user schema is:
Whereas, if you have them both under under the same namespace, you don’t have to do that and Kaffy will detect the admin modules automatically.
schema --> MyApp.Accounts.User
admin ----> MyApp.Accounts.UserAdmin
They are both under the MyApp.Accounts namespace and admin modules must follow the same name as the schema + Admin added to it.
Again, the location of the files doesn’t matter (it’s up to you). The module names are what matter if you want to take advantage of the auto-detection feature.
For functions and business logic, I’d say any function that is beneficial for both your business logic (and maybe Kaffy) should not be in the admin modules. Any function that only works with Kaffy should be in the related admin module. However, you might need to call some business-logic functions inside your admin modules, which is fine IMHO.
Please let me know if you are more confused now
I feel like I’m not 100% clear and I might have added to your uncertainty.
I’m more than happy to provide more concrete examples if necessary.
I am new to Elixir/Phoenix, and I am trying to build admin panel of some of my modules. But I am seeing something strange on many-to-many association, please have a look at it and let me know what can be possible fixes for this issue.
Kaffy doesn’t have built-in support for showing m2m associations just yet. It’s a planned feature for a future version. However, you can easily create an admin module and change the value for the “roles” field to be the correct value. Take a look at how you can customize the index page and let me know if you’re still having issues with it.
Hey @aesmail, How can I pass this conn struct to my admin in resources.
def create_resources(conn) do
[
profile: [
name: "User Actions",
resources: [
user: [schema: Stakester.Accounts.User, admin: Stakester.Admin.ProfileManagementAdmin, conn: conn],
]
]
]
end
end
In create_resourcesconn is returning a struct as it should but in admin module of resource
it is showing something like Stakester.Accounts.User.
I am unable to understand what is going on. How can I my good old conn struct back. I also tried to add conn in resources as you can see but its no use
If you need anything from my side, please let me know.
Hey @kman4you, what do you need to do exactly? conn is passed to some functions but not all of them (yet). I’m assuming maybe you need to customize the fields you’re displaying based on some conn-related conditions. In this case, this is currently not supported. However, I could see how this would be useful and it would be a good feature to add.
Originally, most functions were passed the schema module (as you found out). In later versions, conn was also passed to some functions where it made sense. The general idea is, if conn is useful for a certain function, it should probably be passed as an argument.
If this is what you need, you could add it as an issue on GitHub just for reference and a reminder.
I plan on releasing v0.10.0 soon. This might be a quick fix that would make it for the v0.10.0 release.
Hello @aesmail, thank you for the quick response.
I am trying to make current dashboard user’s management module, (as you can get the idea from example below) so he can perform some actions that he wants like changing his name or email and other stuff like that and I need to get the current_user which is in the conn -> assigns. This is what I am trying to do.
P.S I got your point that currently it is not possible, so I am adding an issue on GitHub as a reminder and waiting for the next release.
If you want to limit access to some resources (showing only resources for a specific user for example), you could actually use custom queries. You could filter the results based on current_user and show that instead of the default result (all users).
Yeah I’ve been meaning to fix that but things got a bit messy locally trying the demo with the unreleased v0.10.0. I’ll try to get it back up as soon as possible.
FYI creating a new item that has a many-to-many relationship fails with
protocol Phoenix.HTML.Safe not implemented for #Ecto.Association.NotLoaded<association :xyz is not loaded> of type Ecto.Association.NotLoaded (a struct). This protocol is implemented for the following type(s): Decimal, Phoenix.LiveView.Component, Phoenix.LiveView.Rendered, Phoenix.LiveView.Comprehension, Phoenix.LiveComponent.CID, Integer, NaiveDateTime, Date, Atom, BitString, Phoenix.HTML.Form, Time, Tuple, Float, DateTime, List
