Hide AppHookConfig admins from the admin list about aldryn-newsblog HOT 11 CLOSED

Maybe that's something that should be differentiated using permissions? For example, let superusers see (and edit) the apphook configs, but hide them for mere mortals?

from aldryn-newsblog.

This case is already handled by the django admin
Wondering if there should be a setting to hide this altogether (related to divio/aldryn-apphooks-config#11)

from aldryn-newsblog.

If exposing it to superusers is already available, I'm not sure why it's necessary to hide it completely. I'm probably not understanding something.

from aldryn-newsblog.

Sometimes (not-so-large deployments) super users are not educated enoughto be able to work on namespaces so this should be protected from accidental changes
Or say you only have one namespace and you don't really need any further setting (see #65)

from aldryn-newsblog.

Right, so it makes sense to have a setting. Hide it by default, but if the setting is True show the admin. That way we can enable it for large and complex installations and most users wont have to worry about this.

from aldryn-newsblog.

Configurable option sounds good. And what about choosing it via the select (foreign key) in admin? Is it ok to keep it visible and editable for everyone allowed to edit the object that has a FK to AppHookConfig?

from aldryn-newsblog.

I was thinking about having a "static" setting that says "show the apphookconfig in the admin index"
Then the rest is up to the django authorization system
Actually what you are proposing is more a row-level permission system, which perfectly fits the scope of newsblog, but I think it's much broader topic

from aldryn-newsblog.

@yakky no objections from me, as long as the newsblog admin forms will be still usable.

from aldryn-newsblog.

No changes wrt forms
It's just a trick to hide the item in the admin list

from aldryn-newsblog.

-1 (sorry!)

I hate to be a dissenter here, but "super user" is by definition one who can control anything. If we're worried that they may do something wrong, this logic can easily be extended to so many other things. Why is apphooks_config more sensitive to "accidental changes" than anything else?

I believe that if a specific project needs this, then, can't that specific project un/register their own admin class to cater to their specific needs?

from aldryn-newsblog.

What we have done, is to update the CMS Toolbar for the app to automatically choose the correct app_config for the users when: producing an Article list or creating a new Article. This should make things very easy and flexible for users who know what they're doing too.

from aldryn-newsblog.