White list mode for non staff members?

[j-osephlong]

This tool really is amazing, we use it often to answer business questions that we haven't built proper views for yet. In fact, I'd love to be able to just hand it to our admins, so that they can answer these sorts of questions themselves, but unfortunately, this tool is only really usable by those with an in-depth knowledge of the database schema. I know this is likely outside of the scope of this project, but I thought I might as well jot down what I think would be required in order for this to happen.

• "Admin-like" registering of models. Similar to how we register models for admin, providing a queryset, listing fields that should be intractable/visible, and providing aggregates. This would allow limiting the view that non-staff have, reducing the noise created by the more tech-y fields.
• Aliasing fields. This would allow fields to be "renamed" in the data-browser to be more descriptive.
• Multiple sites. Similar to how one can create multiple admin sites with different permission levels, this would allow admins to maintain a feature complete and raw data-browser, whilst also having a more limited site for others. (Models would be registered to individual sites rather than a global state)
• Permission checking callbacks. Rather than relying on the staff flag of the user model, a function could be overridden for a specific data browser instance that returns a boolean indicating whether or not the user can access the site.

Again, I know this isn't what this project is intended to be, and feel free to close this.

Thanks again for this project! It really is something else.

[tolomea]

we use it often to answer business questions that we haven't built proper views for yet.

Personally I use it every day. I find it both faster than command line / SQL and more flexible than the admin. But then I'm kinda a power user :P

I also wish I had more time for the project, there are so many things I'd like to improve.

A large part of the core philosophy is to lean into the admin for the understanding of the models and permissions. "If you can see it in the admin you can see it in DDB and if you can't you can't". So it's quite coupled to the admin and I'm not keen to move away from that.

In terms of customization and per user controls, it should reflect all the admin customizability.

It will definitely respect Django user permissions.

It should respect stuff like verbose_name and short_description everywhere, if you catch it not doing that somewhere please do let me know. One detail there is HTML and CSV are considered end user views, JSON is considered a dev view. So JSON specifically does not pay attention to verbose_name etc.

It will also respect you overriding the Admins get_queryset, get_fields and get_fieldsets etc functions, you can use those to customize per user.

There are also some exceptions to the copy the admin approach, places where you can tweak things. You can find these by searching for extra / hide / show in the README. Those exceptions also generally have function versions where you can access the request and hence the user. I'm not opposed to adding more of them if you have specific suggestions.

Multiple sites is an interesting point. I'd never thought about it before but it seems obvious that if DDB is tightly coupled to the admin then if you have multiple admins you should be able to have multiple DDB's. I will have a lil poke around and see how hard that would be to implement. How naughty was I with global variables :)

[tolomea]

Oh, another thing you can do, it drops a flag on request. So you can tell in various functions if it's the admin or DDB calling into admin code. And in the vein another fun admin function to override is has_view_permission. Unfortunately I don't have a list of which of the admin functions DDB uses / respects, but it should be most of the ones that control which models, fields and instances the user can see.

[j-osephlong]

Okay, this was very informative. You're so quick to respond!

I guess nearly all of my points are addressed by the admin coupling philosophy. Slick!

I would love to be able to have data-browser per admin, though. If possible at all, after you poke around and determine if it's a difficult change, I wouldn't mind to work on it myself. Maybe just a few pointers to let me know what you believe is required in sequence, and I could give it a whirl. Of course, if you just want to do it yourself, no offence taken, I just think it could be fun.