Change the submit_batch RPC, and the various bindings of it (PHP, Python, C++)
to support an app_version_num arg,
specifying which app version number should be used to process the jobs in the batch.
- add DB field for storing job keywords: workunit.keywords
add this to various DB parse/write functions
- add --keywords option to create_work for specifying job keywords
- add <keyword_sched> option in config.xml for enabling keyword score
(it's disabled by default).
If set, increment score for "yes" keyword matches,
and disallow jobs with "no" matches
- in scheduler, add array job_keywords_array for parsed versions
of job keywords (vector<int>)
also:
- use symbols instead of numbers for slow_check() return values
- parse unused fields in req message to remove unparsed-XML warnings
new keyword model:
- keywords as identified by integer IDs
- instead of being treated as opaque data,
the keyword XML is now parsed by the client.
This is a first step: pass keywords from AM to client to scheduler,
so that they can be used in job filtering.
Displaying keywords in the client will come later.
Principle: translatable strings should not contain HTML tags.
moderation.php was verbose, and it linked to from the wrong place:
its target audience is forum readers, not writers.
Our current translation system (Transifex) introduced a new editor feature which autodetects C-style placeholders in PO files. This wrongly detects our placeholders in the web code where a word immediately follows the digit. This leads to wrong translations if the placeholder is copied using this new transifex feature. The feature can not be globally disabled for our project. Instead every translator would need to use "raw" mode to disable it which is hard to communicate. Instead I added a space around problematic placeholders which is possing a smaller problem than wrong translations.
In bootstrap.inc there are some functions for creating forms.
They conceal Bootstrap (and HTML itself) from the caller.
I changed a couple of forms (edit user into and create account) to use this API.
There are many other forms that we could change as well.
This is how I'd like the PHP code to evolve:
encapsulate HTML in utility functions.
We have this for tables, forms, and header/footer.
Also finish the NO_COMPUTING changes.
We were asking for postal code (optional) on registration.
The purpose was to let projects study
the geographical distribution of their volunteers.
But AFAIK no one ever did this,
and some volunteers have said (understandably, I think)
that asking for postal code seems like an invasion of privacy.
So I conditioned the postal-code code on a boolean constant POSTAL_CODE.
If you put
define('POSTAL_CODE', true);
in your html/project/project.inc, you'll get the old behavior.
Otherwise users won't see postal-code related stuff any more.
In some cases of file staging (both remote and via stage_file)
we'd do the following:
1) create the .md5 file (in check_download_file())
2) move or copy the file into the download dir
This can result in the file having a later mod time than the .md5 file,
which causes process_input_template() to reject the .md5 file.
Solution: touch the .md5 file after the move or copy
In the "ops" web page showing results, the credit link was wrong.
The page for grepping logs allowed people to run arbitrary shell commands.
Use escapeshellcmd() to prevent this.
However: the Ops interface lets you type in arbitrary SQL,
which lets bad guys do all sorts of things.
So you need to protect access to Ops very strongly.
TODO: fix all vulnerabilities in ops/.
Get rid of the DB browsing features; use phpmysqladmin.
In the default bootstrap file, links happen to be the same color
as "bg-primary" background (why??)
Use bd-default" instead, works OK and both light and dark
David Anderson