The translation code (translation.inc) had a special case
where if the first accepted language was "en", it would show English.
Problem: if the accepted languages are, say, "en-us", "en", "es"
then you'll see Spanish.
Fix: check for both "en" and "en_*" in the special case.
The logic of this code is still flawed, however.
It builds a list $languages_in_use of accepted languages
for which a translation file exists,
and to translate a word it tries these in sequence.
So a page could have translations from several languages.
What it should do is scan the accepted languages until it
finds one that either is English or for which a translation file exists.
Then use that one.
(there could be a check that skips languages for which
the translation is very incomplete).
See http://boinc.berkeley.edu/trac/wiki/PrefsUnification
Discrepancies:
- "Consider the computer in use" pref isn't disabled when the two
"suspend X when computer is in use" prefs are unset.
Doing this would have greatly complicated things.
- day-of-week prefs aren't implemented
No tooltips yet.
Change the way we see if a web server is running on a host.
Fetch http://host, and check for 2xx or 4xx status.
With this change, new server_status.php works on SETI@home.
remote_server_status.php (script for seeing if remote daemons are running)
did this by ps -C command,
and seeing if the last line of the output contained the command.
This didn't work for SETI@home, because the daemons are symbolic links in bin/.
The command that ps knows about is the file name after resolving the link.
This generally doesn't contain the original command name,
so it would look like no remote daemons are running.
Fix: look up the PID (in pid_host/xxx.pid) and use "ps PID".
This also correctly distinguishes between daemons
that use the same program on the same host.
There were a couple of issues:
- the server status page is served from a web server, say X.
A daemon is "remote" if it runs on a machine other than X.
This is not the same as having a <host> element in the daemon's
config.xml entry.
Add logic to correctly classify daemons as remote or not.
- get rid of the <uldl_host> stuff.
There can be separate upload and download servers,
and they are identified by <upload_url> and <download_url>.
They may or not be remote;
to decide this, compare the host part of the URL
with the host part of the project's master URL.
- Hosts are specified with the machine name (e.g. isaac)
or domain name (isaac.ssl.berkeley.edu).
Keep track of this distinction.
The server status page was one of the oldest and cruftiest parts of BOINC.
It flew in the face of the model/view/controller paradigm,
and had the kind of convoluted structure that beginning programmers
often produce.
Plus it didn't work with remote daemons.
The problem is that the web server (running as apache, say)
can't generally check processes on systems, because
- ssh doesn't work (user apache is not set up for it)
- web access doesn't work
(the remote system may not even be running a web server,
and even if it is it may not be set up to let you access the project).
Also:
- use "admin_error_page()" instead of "error_page()" in admin pages
- add footer w/ Main Page link to admin pages
- code cleanup in delete user function
I recently changed the web code to use the PHP mysqli interface if available.
I noticed that it often get "can't connect - too many connections" errors,
even on small projects.
This is probably due to the use of persistent connections, so I took that out.
- get_project_config.php: if project supports LDAP,
advertise this to the client.
- Manager: if project supports LDAP, say "Email address or LDAP ID"
in Attach Project wizard,
and don't do email address validation.
- lookup_account GUI RPC (client side): if passing an LDAP ID,
don't lowercase it, and don't hash passwd
- lookup_account GUI RPC (server side): if passing an LDAP ID,
pass appropriate URL args to Web RPC
- lookup_account Web RPC: in LDAP case, pass "ldap_auth" arg,
and pass "ldap_uid" and "passwd".
Handle these appropriately.
- To use, projects must add LDAP server info in project.inc; see
http://boinc.berkeley.edu/trac/wiki/LdapSupport
- Users can use LDAP name/passwd in login form.
The handlers creates a BOINC account if needed.
- In user page, show LDAP UID instead of email address.
Also, much-needed code cleanup in login_action.php
When deleting a user (from the delete_spammers.php script),
remove records that refer to that user in
private_messages, notify, credit_user, badge_user, and friend tables.
Notes:
- This change eliminates some dangling references,
but in general a BOINC DB doesn't have referential integrity.
The code should check for dangling references.
- Functions like BoincUser::delete() should delete a user record,
not try to remove things that refer to it.
The function delete_user() (in user.inc) does this.
The config option <delete_delay_hours> lets you defer file deletion.
If you set this, say, for 10 days,
then the "results summary in last 24 hours" page will show
jobs that finished 10 days ago and were file-deleted in the last day.
This is generally not what you want.
Change things so that in this case file-deleted results
are treated as if their mod time were 10 days earlier.
Note: this means that the counts of file-delete states
won't be meaningful in this case.
Sometimes (I don't understand why) you get "constant already defined"
warnings for constants in project/project.inc.
This is related to recursive includes.
Principle:
- include project.inc from util.inc (and nowhere else)
- include util.inc from the top-level .php file (and nowhere else)
I seemed to be playing whack-a-mole with problems related to
recursive inclusions of project.inc.
Solve this by changing how the use of mysqli can be inhibited:
instead of defining NO_MYSQL in project, put <no_mysqli/> in config.xml
projects may have developed a lot of PHP code that uses the
old mysql_* interface.
Let them keep using this interface by putting
define('MYSQLI', false);
in project/project.inc
Change all the PHP code to use _mysql_query() instead of mysql_query()
(and similar for other functions).
_mysql_query() uses the mysqli API if available, else the old API.
Going forward, all PHP code should the DB abstration layer if possible;
else it should use the _mysql_* functions.
See http://boinc.berkeley.edu/trac/wiki/PerAppCredit
If enabled (by the <credit_by_app> config flag)
validators will maintain on a per-(app, user, credit type) basis,
and same for teams,
in new DB tables credit_user and credit_team.
This info is displayed in the web site, on user and team pages,
using project-supplied functions to generate the HTML.
Note: update_stats doesn't decay the recent-average values
for per-app credit; I'll add this if needed.
I set out to make project-specific prefs use the same object framework
(PREF_BOOL, PREF_NUM etc.) as other prefs.
This turned out to be infeasible, so I settled for a code cleanup instead.
The reason it's infeasible is that the "other prefs" code
uses a SAX parser (xml_parser_create() etc.),
while the code for project-specific prefs uses the primitive
parse_element() and parse_next_element() functions in util_basic.inc.
If I'm going to change anything, I want to switch to a DOM parser
(e.g. simplexml) for both purposes.
When deleting a spammer, delete
- forum_logging
- private messages
- notifications
Also, when displaying private messages, check if sender
doesn't exist, and delete if so
Having a project symlink its html/ to a different dir doesn't work,
because if you cd into html/ops to run a script,
there's no way to know where the project dir is, so you can't find config.xml
* The previous implementation doesn't work if the /html directory is a symlink
* The new implementation supports symlinks while not adding any additional
assumptions regarding relative file locations
Background:
BOINC's codebase consists of regular source code for compilation as well as
source code for direct deployment, such as the /html folder. Projects might
choose to use a checkout of the BOINC repository and a symlink in their deployed
project root directory targeting the /html directory to facilitate html-related
patch tracking and deployment (in situ). This requires the "html" symlink not to be
resolved during lookups of the project root directory (e.g. to access config.xml).
My last commit did this using a new API call.
But this would require rebuilding apps any time you want to change it;
too much work.
So instead make it an attribute of apps,
which you can set via the admin web interface.
Corresponding changes to client.
Depending on your mail server, PHPMailer can take various config options.
Instead of passings these as variables from project.inc to email.inc,
have project project.inc define a function make_php_mailer()
that creates a PHPMailer object, configures it as needed, and returns it.
For projects that use PHPMailer, this will require modifying your project.inc.
- I'd like to transition from Python (and the clunky
DB interface we developed) to PHP for tools like xadd
- I'd like to figure out how to change the PHP DB interface
so that we can define generic functions like insert(), update() etc.
just one, in a base class.
Do this by putting
define("DISABLE_FORUMS", true);
in your html/project/project.inc.
If this is set, admin users can still see enough forum functionality
to post and edit news items
(this is linked to from the Admin web interface).
Other users, or non-logged-in access, sees news but no forums
or forum-related info.
Spam needs to be deleted, not hidden.
Add buttons for deleting posts and threads.
For now, these are available only to admins
(ADMIN, DEV, SCIENTIST privileges).
It doesn't make sense to show the project banner in admin pages;
the banner typically has (broken) links to non-admin pages.
Also, include basic stylesheets in admin pages.
The latest client reports the peak working set size, swap size,
and disk usage for completed jobs.
Add fields to the results table to store these.
Parse them in scheduler request messages, and write to the DB.
Display them in the result web page.
This data can be used to improve (or even automate)
the job estimates for memory and disk usage.