[drupal-devel] [feature] introduce a "cron" user to fix various cron related issues

[Scott Courtney]

On Monday 14 March 2005 17:33, Bèr Kessels wrote:
> What about following the linux thing, and start counting at 500 for
> normal users? That way people will recognise it, and  numbers do not
> matter anyway. I mean, there is really no difference between 4 and 500,
> other than thats its a different number. 500 makes just as much sense as
> 10, or 2 or 4.

Not a bad idea.

The database purist in me wants to run screaming from this, because in a
purely theoretical sense, having an "arbitrary" ID number begin to mean
something breaks the contract of what an ID number is. That being said, this
may be a case where practicality [rightly] wins over academic purity. :-)

If this happens, it should be very clearly documented because not everyone who
upgrades Drupal will use the automated scripts to do so.

OTOH, if the uid field were to become signed, it might be reasonable to
stipulate that any negative, nonzero uid number has full privileges. This
opens the possibility for sites with shared technical administration, with
the admins each having his/her own "root level" ID, but the logs still show
with more granularity who did what. Better than sharing a single password.
Doesn't require reassignment of any existing UIDs from previous versions,
except for the root user itself which goes from +1 to -1. Theoretically
that specific constant value should only be seen within core code, not
contribs (yes, I know that's an ideal assumption, but probably mostly valid).

While we're on the subject of uid numbers, may I offer an additional
suggestion?

Make uid=0 the anonymous user, and allow it to have "preferences" like any
other user, except that only people with "administer users" privilege can set
those preferences.

Advantages:

* Some things that now have one mechanism (variable table) to set system-wide
  defaults, and someplace else (user profile) to set user-specific overrides
  would save code complexity, because they just do two user-profile lookups
  where one happens to be uid=0 instead of uid=$user->uid.

* Empty returns from database queries are treated numerically as zero in many
  PHP functions, so this change is unlikely to break existing code that relies
  on things like "if ($user->uid) {...". In other words, having $user exist
  but have a uid of zero for anonymous sessions now becomes a possibility.

* Modules could rely on $user object always being present, and that object
  could be created even before authentication is known then populated more
  extensively later.

Scott

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
scott at 4th.com          | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/scott.pubkey