The following query generated an error loading the results (due to issue #129):
http://adslabs.org/bumblebee/ux-class/search/q=bibcode%3A1998A%26AS..133..403M&sort=pubdate+desc

A hard reload caused the following error in the javascript console:

Uncaught TypeError: Cannot read property 'split' of undefined multi_params.js:210Backbone.Model.extend._parse multi_params.js:210Backbone.Model.extend.parse multi_params.js:184Backbone.Model.extend.load multi_params.js:241bound lodash.compat.js:1005_.extend.load api_query.js:68Backbone.Router.extend.search router.js:60(anonymous function) backbone.js:1247(anonymous function) backbone.js:1452some lodash.compat.js:4303_.extend.loadUrl backbone.js:1450_.extend.start backbone.js:1416Mixin.start discovery_bootstrap.js:477(anonymous function) main.js:53fire jquery.js:2913self.fireWith jquery.js:3025deferred.(anonymous function) jquery.js:3114opts.done discovery_bootstrap.js:72fire jquery.js:2913self.fireWith jquery.js:3025done jquery.js:7400(anonymous function) jquery.js:7822

Travis build fails because 'grunt test' is not a valid task (defined in package.json).

Also, I think it will fail further down the road as the discovery.vars.js.default issue is still open (see #43).

$ npm test

> [email protected] test /home/travis/build/adsabs/bumblebee

> grunt test coveralls

Warning: Task "test" not found.� Use --force to continue.

Aborted due to warnings.

npm ERR! Test failed. See above for more details.

npm ERR! not ok code 0

if access_token is not available, because bootstrap didn't finish yet, any api request will fail

also: I should check for errors in the bootstrap phase

I did the following search

http://labs.adsabs.harvard.edu/test/search/q=+bibstem%3A%22ApJ%22

and I see for example in the results

2013ApJ...768L...1A cited: 72

but when I go into the abstract page, the citations tab shows a total of 19 citations.

the latest deployemnt broke query builder - the buttons inside the form are not working; and there were other issues (empty form - validation; stops propagation)

the pagination mixin is adding 'resultsIndex' attribute, which affects how bbackbone treats models in the collection

these edge cases should be tested:

start > 10 && collection is empty
start > 10 && collections contains 5 docs
start == 0 && collection contains 10 docs (0..9)

and probably few others

I had to remove the following rule, to make the query builder display properly (but it lost the 'cool' look)

search-gui {

select, input {
  .form-control;
  height: 28px;
}

}

In commit c9ab6ac you force removal of bower_components. This forces grunt-setup to run bower:install, which uses a broken version of bower. It fails with:

Running "bower:install" (bower) task
>> Cleaned target dir /bumblebee/src/libs
Fatal error: Arguments to path.join must be strings

Does this workflow actually work for you? I have to install+invoke bower manually to avoid this problem.

I'm still seeing CORS errors when running queries on /bumblebee/ux-class/ for brand new queries. Here is what I was able to dig up for an unfielded query of "accomazzi":

1. displayed in the browser's console (in this case firefox):

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://api.adslabs.org/v1/search?fl=id&q=accomazzi&_=1412553356753. This can be fixed by moving the resource to the same domain or enabling CORS. search
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://api.adslabs.org/v1/search?fl=title%2Cabstract%2Cbibcode%2Cauthor%2Ckeyword%2Cid%2Ccitation_count%2Cpub%2Caff%2Cemail%2Cvolume%2Cyear%2Clinks_data%2Cids_data%2C%5Bcitations%5D%2Cproperty&hl=true&hl.fl=title%2Cabstract%2Cbody&q=accomazzi&rows=25&_=1412553356754. This can be fixed by moving the resource to the same domain or enabling CORS. search

1. found in the logs of the front-end server:

96.230.84.139 - - [05/Oct/2014:19:56:05 -0400] "GET /v1/search?fl=id&q=accomazzi&_=1412553356753 HTTP/1.1" 500 291 "http://adslabs.org/bumblebee/ux-class/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0" "-" "-"
96.230.84.139 - - [05/Oct/2014:19:56:05 -0400] "GET /v1/search?fl=title%2Cabstract%2Cbibcode%2Cauthor%2Ckeyword%2Cid%2Ccitation_count%2Cpub%2Caff%2Cemail%2Cvolume%2Cyear%2Clinks_data%2Cids_data%2C%5Bcitations%5D%2Cproperty&hl=true&hl.fl=title%2Cabstract%2Cbody&q=accomazzi&rows=25&_=1412553356754 HTTP/1.1" 500 291 "http://adslabs.org/bumblebee/ux-class/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0" "-" "-"

1. this is the trace of the requests from modsecurity_log:

--969f0178-A--
[05/Oct/2014:19:56:05 --0400] tZmRjYOOuSYAAGakO@QAAAAr 96.230.84.139 56152 131.142.185.10 80
--969f0178-B--
GET /v1/search?fl=id&q=accomazzi&_=1412553356753 HTTP/1.1
Host: api.adslabs.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-BB-Api-Client-Version: 20140329
Authorization: Bearer:LBLMhQx2XGbikXGLDFbrDEcInpTKPfeEvP2RiYlkzFogU69X1hu9vO1fGw17
Referer: http://adslabs.org/bumblebee/ux-class/
Origin: http://adslabs.org
X-Forwarded-For: 131.142.185.25
Connection: keep-alive

--969f0178-F--
HTTP/1.1 500 INTERNAL SERVER ERROR
Content-Type: text/html; charset=UTF-8
Content-Length: 291
Connection: close

--969f0178-E--
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request.  Either the server is overloaded or there is an error in the application.</p>

--969f0178-H--
Apache-Handler: proxy-server
Stopwatch: 1412553365885325 17787 (- - -)
Stopwatch2: 1412553365885325 17787; combined=308, p1=297, p2=8, p3=0, p4=0, p5=3, sr=33, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.1 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache/2.2.3 (CentOS)
Engine-Mode: "ENABLED"

--969f0178-Z--

--969f0178-A--
[05/Oct/2014:19:56:05 --0400] tZmUuYOOuSYAAGpgWTsAAAA3 96.230.84.139 56151 131.142.185.10 80
--969f0178-B--
GET /v1/search?fl=title%2Cabstract%2Cbibcode%2Cauthor%2Ckeyword%2Cid%2Ccitation_count%2Cpub%2Caff%2Cemail%2Cvolume%2Cyear%2Clinks_data%2Cids_data%2C%5Bcitations%5D%2Cproperty&hl=true&hl.fl=title%2Cabstract%2Cbody&q=accomazzi&rows=25&_=1412553356754 HTTP/1.1
Host: api.adslabs.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-BB-Api-Client-Version: 20140329
Authorization: Bearer:LBLMhQx2XGbikXGLDFbrDEcInpTKPfeEvP2RiYlkzFogU69X1hu9vO1fGw17
Referer: http://adslabs.org/bumblebee/ux-class/
Origin: http://adslabs.org
X-Forwarded-For: 131.142.185.25
Connection: keep-alive

--969f0178-F--
HTTP/1.1 500 INTERNAL SERVER ERROR
Content-Type: text/html; charset=UTF-8
Content-Length: 291
Connection: close

--969f0178-E--
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request.  Either the server is overloaded or there is an error in the application.</p>

--969f0178-H--
Apache-Handler: proxy-server
Stopwatch: 1412553365886137 17803 (- - -)
Stopwatch2: 1412553365886137 17803; combined=311, p1=299, p2=8, p3=1, p4=0, p5=3, sr=33, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.1 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache/2.2.3 (CentOS)
Engine-Mode: "ENABLED"

--969f0178-Z--

So it looks to me like the culprit is not CORS but rather internal server errors on the application side. I don't know enough about the docker setup to investigate what goes on there, but maybe @vsudilov can check the nginx logs and see what happened to those two requests?

The sort order needs to be set to pubdate (desc) in all cases except when a second-order operator is present, per BEER compatibility

Clicking 'include' or 'exclude' has no effect whatsoever (Firefox 32.0.3 Ubuntu)

We still have "show more" links which lead to errors in the UI

There are definitely differences in highlighting between beer and bumblebee. See for instance:

http://adslabs.org/test/discovery.html#search/?q=accomazzi+bibcode%3A2005JASIS..56...36K

vs.

http://adslabs.org/adsabs/search/?q=accomazzi+bibcode%3A2005JASIS..56...36K&month_from=&year_from=&month_to=&year_to=&db_f=%28astronomy+OR+physics%29&nr=&bigquery=

Empty affiliations are represented by "-" in the solr document, but I don't think it's clear to just show that to a user. I suggest not having a [Show Affiliations] button (or "gray out" the button) if the authors don't have them, and presenting something like "(none)" in the case that some have them and some don't.

My understanding is that there are assumptions about the existence of some fields within a document when rendering views. All of these assumptions should be removed, as there are plenty of cases of extremely sparsely populated documents.

Marking as bug.

When the server is not available to provide a response to the client, subsequent bumblebee requests generate a long queue of connections which block and do not timeout. This ties up resources both on the client and server end. Suggestions:

• Introduce a timeout on each request
• look into canceling a previous query request when a new one is issued

shim.html is redirecting correctly (with pushState), but any API requests made result in 401 responses from the API. I suspect you're already aware of it, but the problem is that the application does not get the correct token when it bootstraps itself to a certain state.

Abstract for 2014MNRAS.443.1973V does not display properly. The entire abstract is in Solr, but the display seems to have some problems with e.g.

<M_Planck/M_WtG>

deployed the last branch, one can scroll using pgdown/up, and middle button, but when trying to grab the slider (on the right of window) it immediately jumps back

fix the graph facet functionality, improve presentation + css

The [limit to\exclude] context box sometimes does not go away after clicking one of those options, although search is seemingly updated correctly. Latest FF on ubuntu.

when an error happens inside one of the widgets, it should not bring down the application - page managers need to be resilient

1. do the search
2. click on the abstract view (the search form remains empty)

It seems it does not update the element again. see:
http://localhost:8000/test/mocha/discovery.spec.html?grep=Render%20Results%20(UI%20Widget)

bbb is now using oauth access tokens - if a session was open for a long time, they may expire and need to be refreshed

i also need to handle change of access token due to user login

Ok, so after debating this with Vlad we went ahead and hacked the urldecoding function in the oauth library to accept the characters which were tripping up the API. The file in question is $PYTHONLIB/site-packages/oauthlib/common.py, and the change is this:

#urlencoded = set(always_safe) | set('=&;%+~,*')
# XXX 
urlencoded = set(always_safe) | set('=&;%+~,*!()')

It seems like this is failing because of a strict interpretation by the OAuth library of the urlencoding spec. Roman when you're back we should fix this so that the request is fully encoded when created by the javascript application. But at least this adds back the author faceting functionality.

sometimes the children that inherit from this widget, after publishing a single this.pubsub.DELIVERING_REQUEST, receive two DELIVERING_RESPONSES. However this doesn't happen consistently.

grunt setup fails under bower:install with Fatal error: Arguments to path.join must be strings. Seemingly this is due to a broken bower packaged with grunt.

A workaround is to install bower and invoke manually a la:

npm install bower
bower install
grunt setup

Secondly, the application will fail since it can't find discovery.vars.js. I guess you intended for people to edit/rename discovery.vars.js.default, but it would be nice if this were documented.

I'll change the manifest to reflect the bower issue, @romanchyla could you document discovery.vars.js, at least from the standpoint of deployment?

Reproduceable by inputting any query that returns nothing: ^foobarbaz for example

I think the UX would be significantly improved by having a global loading indicator on bootstrap, such as the "initializing the awesome" indicator on jsfiddle.net. Currently, the user sees only a blank page during the entire initialization.

pls look at comments in #70

In the abstract page view, when one calls up the list of references they should be sorted by first author name. Citations should be sorted by pubdate (descending).