beat.web issueshttps://gitlab.idiap.ch/beat/beat.web/-/issues2017-08-06T16:44:51Zhttps://gitlab.idiap.ch/beat/beat.web/-/issues/467Possibly no plotterparameters for bar plots2017-08-06T16:44:51ZJaden DIEFENBAUGHPossibly no plotterparameters for bar plotsSee jdiefenbaugh/beat.web#19 and jdiefenbaugh/beat.web#17 for some background info if needed.See jdiefenbaugh/beat.web#19 and jdiefenbaugh/beat.web#17 for some background info if needed.https://gitlab.idiap.ch/beat/beat.web/-/issues/468Merge button not shown in bar plots2017-08-23T11:36:42ZJaden DIEFENBAUGHMerge button not shown in bar plotsSee jdiefenbaugh/beat.web#17 for background info.
Should the merge button be shown for bar plots? If so, this is a bug.See jdiefenbaugh/beat.web#17 for background info.
Should the merge button be shown for bar plots? If so, this is a bug.https://gitlab.idiap.ch/beat/beat.web/-/issues/469Upgrade angular dependency (and possibly others as well)2018-10-31T08:20:05ZJaden DIEFENBAUGHUpgrade angular dependency (and possibly others as well)Beyond maintainence (see Angular's [changelog](https://github.com/angular/angular.js/blob/master/CHANGELOG.md) which has hundreds of bug fixes since 1.4.5), there's a few reasons I'd like to upgrade (in order of concreteness):
1. Custom ...Beyond maintainence (see Angular's [changelog](https://github.com/angular/angular.js/blob/master/CHANGELOG.md) which has hundreds of bug fixes since 1.4.5), there's a few reasons I'd like to upgrade (in order of concreteness):
1. Custom comparators for ordering elements (e.g. multi-column sorting, see jdiefenbaugh/beat.web#22)
2. Performance improvements which would help smooth the UX
3. Lets us upgrade jQuery to v3
4. (ties in with 3) lets us track the current development/maintenance of Angular 1 & its ecosystem
As far as breaking changes go - there's not much, since we're just using standard Angular features:
1. There might be an issue with [`$sce`](https://docs.angularjs.org/api/ng/service/$sce), Angular's utility for sanitizing strings before using them in things like resource URLs or dynamically-compiled HTML. Angular may require using `$sce` more often in our code, if we use complex `$compile` calls or use dynamic resource `href`s in our templates.
2. Angular's custom `success` and `error` methods for calls to `$http` have been deprecated and then removed. They now recommend using the official JS solution, `then` and `catch`, which have huge browser support & more features. There aren't many instances we need to change, either. A quick grep shows:
```
beat/web/ui/static/ui/js/reportdialog.js
153: .success(function (reportData)
160: .error(function (error)
250: .success(function (reportData)
257: .error(function (error)
273: .success(function (reportData)
280: .error(function (error)
394: .success(function (reportData)
401: .error(function (error)
beat/web/plotters/static/plotters/app/controllers/plotterparameterController.js
64: .success(function (plottersData)
72: .error(function (error)
83: .success(function (plotterparameterData)
124: .error(function (error)
beat/web/plotters/static/plotters/app/directives/plotterparameterItemView.js
201: .success(function (returnedData)
207: .error(function (error)
252: .success(function (returnedData)
257: .error(function (error)
314: .success(function (returnedData)
319: .error(function (error)
381: .success(function (returnedData)
386: .error(function (error)
beat/web/reports/static/reports/app/directives/saveReportItems.js
35: .error(function (error){
```2017-05-19https://gitlab.idiap.ch/beat/beat.web/-/issues/489Invalid requests for the `reportSingleTable` partial2018-10-31T08:08:19ZJaden DIEFENBAUGHInvalid requests for the `reportSingleTable` partial##### What's the issue?
Somehow the `reportSingleTable` partial, a file removed awhile ago, is still being requested by the client via this file's (now defunct) entry in the reports' `urls.py` file. Django throws a 500:
```
Internal Serv...##### What's the issue?
Somehow the `reportSingleTable` partial, a file removed awhile ago, is still being requested by the client via this file's (now defunct) entry in the reports' `urls.py` file. Django throws a 500:
```
Internal Server Error: /platform/reports/partials/reportTable/
TemplateDoesNotExist at /platform/reports/partials/reportTable/reports/partials/reportSingleTable.html
```
The only reason that Django is throwing a 500 at not being able to find a resource (instead of a 404) is because this removed file is still registered in the `urls.py` file:
```python
partial_patterns = [
#...
url(r'^reportTable/$',
views.PartialGroupView.as_view(
template_name='reports/partials/reportSingleTable.html',
),
name='table',
),
#...
]
```
If I had properly removed all references to this file (oops) this bad request would have returned a 404 and we wouldn't have been alerted.
##### How is this happening?
After looking into how this file is being requested, I'm guessing that this is an issue with client-side caching. Browsers cache HTML/JS often, assuming that once you visit a page that you are willing to sacrifice disk space to revisit the page faster. I believe that (some?) browsers are keeping old versions of the BEAT platform's client files in the cache. These old files have the old code in them, and request the old resources.
This almost always isn't a problem, since it's easy to compare file versions and invalidate the cache appropriately. However I've had this problem before when working locally & on staging. I figured it was just because of how quickly I switched through different versions of the BEAT platform, but I think it's happening on prod to normal users too.
Why would this be an issue for us and not for 99% of other websites? Honestly I don't understand enough right now to answer that. I *do* know, however, that servers can influence the caching of browsers...we might not be handling things properly.
##### What do we do?
There's still a small chance that this issue isn't caching, which would be much easier to solve. We should look into the issue a bit more. If it really is a caching issue, we'll have to do a few things:
- We may have to ask users to manually clear their cache for the BEAT platform. As Andre suggested, we can add this to the FAQ.
- There's probably other resources being requested by old caches that aren't throwing 500s but 404s instead. We might want to monitor 404s for now as well as 500s.
- There might be a fix on the Django side to automatically/manually invalidate existing caches. Maybe we aren't doing something properly when serving the client files?
- Client-side, we should check to see if bad requests are handled properly so the user is aware of the issue and of potential fixes (such as looking at the FAQ, clearing the cache, filing a bug report, etc.).
- We'll want to try to reproduce the cache issues (maybe even add a test for it?). The complexity of the problem is greater than our testing infrastructure, so this would take awhile.