Need an option to view annotations by a less powerful user

[eepeacock]

We have a use case that we have not yet encountered. I have a lab assistant who is subdividing an existing category. When he adds an annotation to an already annotated image, there is not currently a way to have it displayed under the new category. Even if I log in to look, it is still displayed where I had put it originally.

Brainstorming is welcome on this, but one option would be to either be able to chose "display annotations by user_____" and then chose the user. Another good option might be "display most recent annotation".

Because I can imagine if I do some work on the same project the lab assistant is working on, I might want to then be able to override what they did. Mostly I would go in and verify the work of the lab assistant.

This is a bit of a logic problem. Again, brainstorming welcome. Let me know if you have any questions.

[hsosik]

Lou and I already talked about this problem and we came up with an idea that might work. Lou is going to enable an option to display classifications according to the most recent annotation event (as opposed to the event done by the user with the highest power). That option would allow a high power user to verify new annotations made by someone with lower power--then go back to the standard option of displaying by power.

[joefutrelle]

What about the case where there have been multiple new annotations on the same ROI that need to be reviewed? Under this proposal you'd only be able to review the most recent one.

[hsosik]

You mean two low power users made annotations that don't agree? In that case, I guess we'd be having the high power user review the last one and either agree with it or fix it. I'm not sure why it would matters that there was an earlier low power annotation. Am I misinterpreting what you mean?

[joefutrelle]

No misinterpretation, that's what I meant. If it's not a problem, then great!

[eepeacock]

Has there been any action on this that could be installed? It is a
little bit high priority, because Gedeon is working away, but we still
lack a way for him to view his annotations in their new classes.

Quoting Joe Futrelle notifications@github.com:

No misinterpretation, that's what I meant. If it's not a problem, then great!

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/LouisK130/Manual-Classify/issues/39#issuecomment-399206630

[LouisK130]

I've added something that should help for now. It's quick and dirty and doesn't account for tags yet (i.e. even if you select "Most recent", tags will continue to be accepted or negated based on power level alone).

I didn't test exhaustively, let me know if something seems not be to working as intended. In particular, I'm not certain about the interactions between this new ordering and the auto-classifier results.

It also might be worth noting that this doesn't completely mesh with batch mode right now. Batch mode attempts to filter out any bins that will have 0 relevant targets (with "relevant" meaning that the target(s) belong in the category of interest). Since you now have some real-time control over which targets belong where, this upfront filtering doesn't really make sense anymore. I don't think this should be an issue for your current use case with the lab assistant, though.

[joefutrelle]

I still haven't been able to get the new version to work on our server, I can provide details in another issue.

[LouisK130]

Yeah, please post details and I’ll take a look.

[joefutrelle]

misspoke, I was talking about not being able to get v2 to work, this fix appears to be in place now, need someone else to help test it.

[eepeacock]

It didn't work for me. If I tried batch mode on 2006 or 2007 with
Chaetoceros, it just stayed "loading" indefinitely. If I tried the new
Chaetoceros category, which only has annotations by Gedeon, it said
there was an error with one or more bins- which is usually what it
does if there are not any annotations in the chosen time period for
the chosen class.

Quoting Joe Futrelle notifications@github.com:

misspoke, I was talking about not being able to get v2 to work, this
fix appears to be in place now, need someone else to help test it.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/LouisK130/Manual-Classify/issues/39#issuecomment-400392219

[LouisK130]

@joefutrelle I'm not sure what's going on here. I'm testing on two bins:

http://ifcb-data.whoi.edu/mvco/IFCB1_2007_010_001739.zip downloads fine from my local version of Annotate, but 404s from the live version (at https://ifcb-annotate.whoi.edu). To reproduce, go to the live version, input this bin, and classify raw. Check network tab in Chrome debugger, and note that the call to /getzip is a 404 response. /getzip looks up the zip on the dashboard, finds a 404, and forwards this response to the JS client, which in turn tries to read it as the contents of a zip file and fails, resulting in the "indefinite loading" Emily is describing.

On the other hand http://ifcb-data.whoi.edu/mvco/D20180525T142354_IFCB010.zip works perfectly fine from both versions.

Does the live version differ from the current master branch in any way?

[joefutrelle]

I'm not getting a 404 for

http://ifcb-data.whoi.edu/mvco/IFCB1_2007_010_001739.zip

[LouisK130]

Through the application, or through your browser? I can download it fine from my browser, but when https://ifcb-annotate.whoi.edu/ tries to access it, I see a 404. It's possible that the application builds the wrong URL, but then I can't imagine why http://ifcb-data.whoi.edu/mvco/D20180525T142354_IFCB010 would work fine.

Check out this screenshot; it should clarify what I mean.

[joefutrelle]

To answer your earlier question, the live version is the current head of master.

I do understand exactly what you mean, but I can't independently verify that the dashboard is returning a 404 on that URL. When I use wget with that URL on ifcb-annotate, I get a 200. When I use Python requests with that URL on ifcb-annotate, I also get a 200.

I think the next place to look is the dashboard server logs, I can try that next.

[LouisK130]

Go ahead and pull what I just committed to master. It should give us some more descriptive logging of this issue and resolve another.

[joefutrelle]

In the logs, the only 404 I saw for that bin is when the request had the wrong namespace:

/NESLTER_transect/IFCB1_2007_010_001739.zip

[LouisK130]

Yeah, I thought that #22 might be the underlying cause of this. The most recent commits should have resolved that, and hopefully this as well.

[LouisK130]

You should also clear the cache. I had mistakenly been allowing a failed zip download (like a 404 response) to be written to the cache. If the cross-session timeseries issue occurred once, the bad result was probably cached and would persist even after this fix.

[joefutrelle]

OK, updated and cleared the cache.

[LouisK130]

Great, seems to have resolved the indefinite loading issue.

[eepeacock]

I still have indefinite loading... I tried logging out and logging in
again. I also tried just one bin instead of the whole year.

Quoting Joe Futrelle notifications@github.com:

To answer your earlier question, the live version is the current
head of master.

I do understand exactly what you mean, but I can't independently
verify that the dashboard is returning a 404 on that URL. When I
use wget with that URL on ifcb-annotate, I get a 200. When I use
Python requests with that URL on ifcb-annotate, I also get a 200.

I think the next place to look is the dashboard server logs, I can
try that next.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/LouisK130/Manual-Classify/issues/39#issuecomment-400441581

[LouisK130]

What bin(s) and/or date ranges are you trying to see, and in what timeseries?