GitLab

Changed style as per Leigh's request:
 - no lines longer than 80 columns
 - removed some of the more abrupt ?>...<?php
   "leaping in and out of php" constructs;
   left some in.

The big one.

New look;
most of the changes are in menu.php3.

A lot of the changes in other files are s/<TD>/<TH>/
for table headers.

Also closed some tags, tweaked some table styles, etc..

No actual functionality should have changed.

Will be installing soon...

Add Austin to current people.

adminmode). Red means DANGER!

Banner bar to indicate what you are. Click the dot toggles the mode.
Might have the colors backwards though. Perhaps green dot should
indicate adminmode is off and red dot indicate on?

changes that have to go in now!

conditionalized on isadmin() status. These pages were mostly
overlapping anyway, and the nodecontrol_list.php3 page was done more
cleanly. No point in all the duplication. Dropped the Node Control
menu item from the list.
Add explicit "widearea" view to get remote nodes in their own page,
instead of listed after all the PCs. Also some minor formatting
changes.

netscape gives when logged in using another browser. Most of the
problems stems from the desire to allow users to refer to the main
page in http mode even when logged in. I want to draw the menu as if
logged in, but have the actual pages demand https mode. I'm also
trying to catch the case where users have turned off cookies. I think
Mac's idea is the way to go, but I don't want to mess with it right
now. These changes will avoid the worst problem.

* Cleanup! A lot of the structure derived from the early frame days,
  which had a noticable (and bad) effect on how I wrote the stuff.  I
  cleaned up most of that yuckyness.

* In process, optimize a little bit on the queries. The old code did
  about 9 queries just to write out the menu options, and then
  repeated most of those queries again in the page guts. I've
  consolidated the queries as much as possible (to 3) and cache all
  the results.

* Fix up problem with users who forget their passwords before
  verification. Basically, I fixed the more general problem of not
  being able to update your user info before verification/approval;
  users now get that menu option no matter their status.

* Fix up problem of users being able to access pages before
  verification (but after approval) by going around the menu options.
  The page level check (after the menu is drawn) now checks all
  conditions (password expired, unverified, unapproved, timedout, and
  also nologins()).

* Minor change in approveuser; do not show the new account to the
  project leader until the new user has verified his account.

* Change verification method, as reqwuested by Dave.  In addition to
  providing the key, also provide a web link to take the user straight
  to verification. I actually take them direct to the login page, and
  pass the key in as an argument. If the user is already logged in,
  bypass and go directly to the verify page (not the form page of
  course).  If the user is not logged in, let him log in, and then
  forward the key onward to the verify page. Basically, bypass the
  form all the time, and just do the verification.

* Minor change in showuser; Do not show pid/groups not approved in,
  and if the count is zero, do not draw the table headings.

out included directives to prevent caching along the way. Now we look
at the protocol (http vs https) and include directives that allow
(encourage) http pages to be cached for a short time. My reasoning is
that anything we spit out via http is documentation, and can grow a
bit stale. Sure, the menu on the left is dynamic, but not so dynanic
that it can't go a little stale too for people who are not logged in.

when backing up (cause of an error that needs to be fixed) since not
all browsers handle this the same. Instead, redraw the form with all
of the original info and a list of error messages at the top.
Conceptually simple change, but it turns out to be a pain to implement
since you need to combine the form and processing code in one page
(well, its just a lot easier to do that), and then change all of the
forms to deal with a "default" value. That is, each different kind of
input tag (text, radio, select, checkbox, etc.) requires slightly
different changes to do that. Lots of forms, lots of entries on the
forms, and its a long slow tedious process. Much nicer though, although
the code is a bit harder to grok. At the same time, I added a lot more
sanity checks of the information being passed in.

The other change is to deal with how browsers handle the back button
on a form thats been properly submitted. Not all browsers use
the cache directives the same, and I was often typing back, only to
have some form get reposted. Thats a major pain in the butt. The way
to deal with that is to have the processor send out a Location header,
which modifies the browser history so that the post is no longer in
the history. You back up straight to the unposted form (if its in the
cache). I've done this to only some forms, since its a bit of a pain
to rework things so that you can jump ahead to a page that spits out
the requisite warm fuzzies for the specific operation just completed.

I've done newproject, joinproject, update user info, newimageid, and
newimaged_dz forms.

gets spit out a lot in all of the pages (http or https).
Refine fonts and little bits in the banner.

the bottom of the page need to be localized, but wasn't in the mood.

(somewhat) so that we can do submenu easily in other pages.

already 99 percent the same, so no need for a different form and a
processing page. Just add a checkbox and footnote on regular page.

experiment info page redraw every 30 seconds when the exp state is in
the activating or swapping state. Eventually will stop when the state
changes.

in. This was mostly to support the modal change in the home link, but
since people do not like that, this stuff is probably going to get
tossed at some point.

tired of clicking through to find my own info and experiments.

capability. New DB field in the users table (pswd_expires) which is a
date field that initially gets set to one year after the user account
is created. When the password is changed via the web form, it gets
bumped 1 more year into the future *unless* the current uid is
different from the target_uid (ie: you are changing a password for
someone else). In that case, the expiration is set to the current
date, which forces the target user to change his password next time he
logs in. I've changed the menu/auth code to look for password
expiration, and when expired the menu options contain just a single
option to change the password. All other https pages will fail with a
password expired message. Normal text pages will work of course.

webglimpse dir right into search.php3. Its a simple form and I wanted
it to look a little different. It also allows me to get rid of the
FollowSymlinks change I made a couple of days ago. I've added a
install section that creates a symlink to the webglimpse dir, but
thats strictly for convenience. The install target cds into that
directory and reruns the glimpse index (its very quick cause we do not
have much documentation, perhaps a second. Overall, I do not like the
webglimpse stuff, but it will do for now.