We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 5396 - Move reviewer interests to article_search tables
Move reviewer interests to article_search tables
Product: OJS
Classification: Unclassified
Component: Search/Indexing
PC Mac OS X 10.3
: P5 enhancement
Assigned To: PKP Support
Depends on:
Blocks: 5478
  Show dependency treegraph
Reported: 2010-05-05 10:03 PDT by Matthew Crider
Modified: 2010-06-28 11:48 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects: OCS 2.3.2, OMP 1.0


Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Crider 2010-05-05 10:03:33 PDT
We should move the reviewer interests to article_search tables (or some table adapted/abstracted from them) to allow for boolean searching of reviewer interests.  See http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=6072&p=23225#p2322
Comment 1 Matthew Crider 2010-06-03 14:17:11 PDT
I've implemented this in a new table (interests) thats fairly generic, i.e. it uses assoc_type/ID for identifying users--So this could be extended to other keywords.

This structure will work well for the advanced reviewer search in OMP, but I'm not sure how it will work for searching reviewer interests in OxS--I might have to look into indexing the table (or implementing what's going into OMP in OxS at the same time, e.g. filtering reviewers on whatever interests the editor selects).

Comment 3 Alec Smecher 2010-06-12 00:51:32 PDT
Matt, I'm not able to save my reviewing interests in either OJS or OCS HEAD at the moment -- the reviewer interests field appears, but no text that I add there appears to be saved.
Comment 4 Matthew Crider 2010-06-28 11:48:10 PDT
Fixed...  I forgot to port the latest small change from OMP to the other apps.  FYI, the change was in the JS to automatically name the keywords (grouped as an array of hidden inputs) based on the keyword input's ID. So, 
Will create a keyword input control, and as keywords are entered, they are stored in 'interestsKeywords' (and can be accessed through the Form class using that name).

They were previously named just 'interests', which wouldn't work if there are multiple keyword inputs on one page.