Django admin suitable for external users?

[Joshua Pokotilow]

Hello! I just had a fairly lengthy conversation with my colleagues about whether or not Django admin is well-suited to external users outside our company. I took the position that for certain use-cases, exposing Django admin to third parties makes a lot of sense, given that the admin application has all kinds of features baked in that are well-suited to certain admin tasks (ACL, customizable templates, dynamically built CRUD forms, etc.). Unfortunately, I met with a lot of resistance on account of fears over ease of customizability, security, and technology lock-in. Furthermore, there was some concern that exposing Django admin to third-parties might send us off the beaten path, and that doing so could be an antipattern.

I would appreciate knowing how other developers feel on this subject, and would love to hear about how some larger companies that use Django (Instagram, Disqus) think things through.

Thanks.

[Bill Freeman]

How technical are your users?

What are your security constraints?

How much work can you do to make it "pretty"?  (Believe me, someone will ask.)

Are there fields that you want to administer internally but don't want to expose to the users?

Will your users object if you decide to move to a newer Django version and the interface changes/

You can make it work, but in many instances it will save you less effort than you though (might even be harder).

A few custom views are pretty easy to roll out.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/59231ea7-4bd1-41c2-97ef-f294a380bcb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luis Zárate]

I suggest you to create a custom admin site for your external user where you expose only the models that interact with the external user and create a middleware for forbidden access to the other admin site.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0tme%3DvZdzKBf5ygJRqtACozy2ugi5qyKjG5WHDWENkUWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

"La utopía sirve para caminar" Fernando Birri

[Joshua Pokotilow]

How technical are your users?

Not very technical, necessarily. They're normal end-users.

What are your security constraints?

We're in the medical industry, so security is a key consideration for us in general. I think the main concerns about Django admin specifically were that it encompasses so much functionality, we might wind up shooting ourselves in the foot by failing to lock something down properly. Also, there might be discoverable exploits since it's an open source product.

How much work can you do to make it "pretty"?  (Believe me, someone will ask.)

I believe the hope is that we wouldn't spend anymore time making it pretty than we would spend if we wrote our own custom HTML. We don't have strict style guidelines we would need to adhere to, except maybe for the header / footer.

Are there fields that you want to administer internally but don't want to expose to the users?

Yes, but I think(?) this can be tailored to the logged-in user.

Will your users object if you decide to move to a newer Django version and the interface changes/

I think it's possible they would, but perhaps not too much.

Thank you for the insights!

[Joshua Pokotilow]

That's an interesting idea. Thanks.

I suppose it's possible to register models with two different admin sites, although I've never tried doing that myself.

[Luis Zárate]

Sure, you could have several admin site with the same models.

I read an specific page about how to do that, but right now can remember what is the specific url.

Those other links could help you.

https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#the-register-decorator
http://blog.tryolabs.com/2012/06/18/django-administration-interface-non-staff-users/

the specific class than provide admin site feature is django.contrib.admin.sites.AdminSite

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8f4edbde-28b5-4002-99e1-d08ea7c30f3b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Allen]

It really depends on the project you're working on. The resistance comes mostly from developers who utilize the admin as an open interface to the database with minimal restrictions. I like to use the admin this way for large projects that are used by many people, building out a custom "staff" portal for non-technical staff users (more data validation, form helpers, general improved UX) and using the Django admin strictly for developer use. 

I have built smaller projects, generally standard brochure style sites (things most people would use Wordpress for) and used the admin as the CMS for the client. I only ever customized the nav bar with client brand name/colors and utilized the options on the ModelAdmin object to make it as convenient as possible. Never had any complaints, it's pretty straightforward and still allows you to upgrade Django gracefully.

[Joshua Pokotilow]

Thanks Ryan. That's an interesting additional consideration. I don't think we're particularly married to Django admin as an open interface to the database where I work, although I can see how that wouldn't always be the case. Also, I think Luis's suggestion could help to quell the resistance you cited.

[Derek]

I'd say for non-technical users, you may want something custom; particularly if they are only working with a smaller sub-set of the data.

We have users that are fairy technical (working in the science domain) that are used to large grid-like data displays (typically in spreadsheets).  So, for them, the admin interface makes sense; and be aware that there is a *ton* of customisation you can add to the interface (e.g. actions; third-party "skins") to make it more "user friendly".  

You can, of course, start with the admin and then expand it / add-on custom functionality as needed over time - its not an "either/or" situation.

(PS You can send a private email if you need details on how our project works.)

On Wednesday, 23 September 2015 23:39:58 UTC+2, Joshua Pokotilow wrote:

How technical are your users?

Not very technical, necessarily. They're normal end-users.

[ta...@pingmd.com]

Has anyone opened Django admin to customers, not just clients? If so, what warranted such decision as appose to only exposing partial functionality through a customized app?

CONFIDENTIALITY NOTE: The information contained in this transmission may be privileged and confidential, and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.

[Derek]

What is the difference between a customer and client - I assume the former is paying?

[ta...@pingmd.com]

Derek, my distinction would be based product ownership ... potentially both would or could pay. So in other words "clients" would own the product as their own, versus "customers" whom are paying for service without ownership and control of product development.

I have seen Django admin opened up to clients & partners as a content management system but never have experienced it as a consumer product.

[Derek]

I agree that for widespread "unknown" customers its probably not good.  I think that when working in close partnership with a small number of clients/customers (the way the funding is works is not really a big issue), who will receive training and a good user manual, then the admin (with some user-friendly tweaking) can be used.  I am also assuming that, in all likelihood, that other tools such as queries, data capture and visualisation tools will be built as is appropriate.