The boundary between infrastructure and business logic

Using Django
1

I am not asking for advice. And maybe I am writing in the wrong place. Although I hope that someone more experienced will help me solve the problem, but judging by the documentation, this is not possible.

I’m talking about the field “is_staff”. Disabling it leads to a whole series of errors. And the problem is easy: a superuser must be a staff.
Damn, sorry developers, but that’s none of your business. This is no longer a matter of infrastructure, it is a matter of business logic. It’s simple, if I decided to make this user a superuser, then go to hell with your field is_staff.

Sorry if this violates community guidelines in some way. Sorry if this isn’t interesting. But friends, it’s really bad form - to impose your view of life on the user. :face_with_symbols_over_mouth:

Once again, I beg your pardon.

2

There is another way of looking at it. Those fields exist to support internal Django functionality, and if you need to support some other organizational structure, that’s up to you to provide.

Your attempt to use is_staff for your business logic is where the problem lies. If you’re trying to control access to parts of your system to individuals, you should be using the groups and user_permissions system, not is_staff and is_superuser.

Quoting directly from the documentation

is_superuser

Boolean. Designates that this user has all permissions without explicitly assigning them.

and
is_staff

Boolean. Designates whether this user can access the admin site.

Note that neither of these provide any indication that it’s proper or appropriate to use them for any other purpose. The Permissions and Authorization section of the docs describe what facilities you should be using to control access to parts of your site.

Oh, and while the discussion of the design decisions made for Django are appropriate, there’s no need to be belligerent or hostile with your approach. There’s no need for invectives, and I would kindly suggest you tone it down a notch.

4 Likes
3

Thanks for your reply and advice. Believe me, I am 54 years old, of which I have been programming for 40 years. I know how to use groups to manage access.

On the contrary, I don’t need this field at all. I just want to turn it off. Turn it off completely. I do not need the distribution of permissions. I just don’t need the junk in the user class.

It was a cry from the heart. I just wanted to show that sometimes the pursuit of functionality goes beyond reason. Every time a system developer introduces a new function, he must ask the question whether he is crossing the border, and whether he is intruding into the sphere of business logic.

4

I’m not following your train of thought here. It’s a field you don’t need, so just ignore it. It’s just like all the other features of Django that you may wish to not use.

You’re wrong here though, by continuing to say that this “is intruding into the sphere of business logic”.

As I’ve pointed out, and it is documented as such, “is_staff” has nothing to do with business logic. You are misinterpreting its intent and purpose. You are making a connection between Django internals and business logic based upon the name of the field, where no such connection exists. (And, by the way, this field is not new - this field was a long standing entity within the User model from before I started working with Django.)

Since is_staff is a field within AbstractUser and not AbstractBaseUser, you could create a custom User class based directly on AbstractBaseUser. Just keep in mind that it will break the admin facility and you will need to provide a custom UserManager.

5

Yes, of course, Ken, thanks, I went this way. I created a user model from AbstractBaseUser and rewrote UserManager. I don’t really care (in this particular project) the admin’s functions, since the project does not imply its presence in its usual form; not at the production stage, not at the debugging stage.

Thanks again. I will only note that very often our colleagues proceed from two convenient for them, but philosophically incorrect postulates. First: “it was like that before us and it happened historically.” Second: “if it works, then don’t touch it!” These two rules are good if there is no possibility or no ability to think in abstractions. Therefore, from project to project, we see unnormalized tables and classes, attributes and fields that do not correspond to the object or class, and just a “crooked” code. This is an eternal struggle between the Simple and the Right, as Rowling wrote.
Think about it, if we started with a clean slate, what would we need to make a superuser stand out? You can even skip creating the “is_superuser” field, since in 99% of cases the first user in the database is an administrator. In other words, the task of rights and access to the admin site can be solved more elegantly.

And in business logic, the “is_staff” field is an attribute of another entity. Moreover, this is not an attribute at all, it is a link (ManyToMany) between the Person class and, for example, Profile, Position or Role, or Organization class, and etc. Exactly like the User is correlated with the Person by the OneToOne. This is what I meant. Likewise, admin access is owned by the group.

The task of assigning rights is quite different, thanks for your clarification. But as they say in consulting, if the client did not understand something, this does not mean that the client is a fool, it means that the consultant explained poorly. And at least in the fact that the name of the field was not chosen well (I do not use keywords for variables), I think I’m still right. :slight_smile:

Thank you for your feedback. Thank you for participating. All the best to you! :slight_smile:

1 Like
6

Just a couple of minor points I’ll add here.

First, addressing the comment “it was like that before us and it happened historically.” I can agree that it is a “philosophically incorrect postulate”.

However, we’re not talking philosophy here. Django has the stated objective of not introducing unnecessary breaking changes. There are a number of artifacts of original design decisions that would be made differently today if we were starting from scratch. But we’re not. We’re talking about a mature, stable environment with thousands of existing installations. To change the implementation details of something as fundamental as the User object would require an overwhelmingly convincing case be made - and the opinion of a suboptimal selection of a variable name isn’t going to do it. (Think of it as the software development version of stare decisis. A very strong case needs to be made to override a previous decision.)

Second point: You wrote “And in business logic, the “is_staff” field is an attribute of another entity.” You would be correct if “is_staff” were in any way associated with business logic. But it’s not. It’s a Django-internal reference, with no association to “user-level” facilities such as Group or Permission. Its functionality is internal, and must not depend upon those other features to avoid conflicts in that realm.

Like many other terms, the fact that the word “staff” is overloaded with multiple meanings shouldn’t be a sticking point. (If anything, you could think of the real name of this field as being “is_a_member_of_the_django_system_administration_staff”. The reasons for this name come from Django’s roots as an online-newspaper publishing facility, where is_staff referred to the writers who would supply content.)

Finally, is_superuser is still going to be required for any environment with more than 1 superuser - and every installation I’ve done has at least 2 and usually 3. People don’t share accounts and people need backups and alternates. Sharing a superuser account is an auditing and compliance nightmare. Also, the first user created, AKA the original superuser, may end up being removed from that role but needs to retain their account. Those permissions need to be able to be revoked.

Cheers!

1 Like