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.
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
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.
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.
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.
- the exported team list wasn't parsing due to non-ASCII characters
in some team descriptions.
htmlspecialchars() wasn't doing the job.
Use DOMDocument instead.
- If SHOW_NONVALIDATE_TEAMS is set (as on the BOINC-wide teams site)
show teams whose founders email addresses are not validated
(and hence won't be exported).
On some hosts, gpu_active_frac may be much less than active_frac
(i.e., GPUs may be available much less than CPUs).
Use gpu_active_frac in the following places:
- scheduler: in estimating the elapsed time of jobs,
to decide whether they can meet deadline
- scheduler: in computing the effective speed of a (host, app version),
when deciding what size class it belongs to
- size_census: in computing effective speed of (host, app versions)
(Previously, we were just using active_frac in all these cases)
- gpu_active_frac is the fraction of time GPU use is allowed
while the client is running.
Previously the client reported it but we weren't storing it in the DB.
We may need it in the future for batch scheduling logic.
- fix a crashing bug in scheduler
- client: minor message tweak
- add delete button
- show # of badges assigned
- don't use separate head/tail function are admin pages
- add badge assign task for new projects
- turn on db_dump, update_uotd, update_forum_activities,
update_profile_pages, notify for new projects
David Anderson