Annotation Numbering Issue

[yebyen]

I just uploaded about 17 images of my server room and I set out to annotate and label all of the things...

I noticed that while the numbers were basically going up at about the right rate, a lot of my annotations had the same number! For example, this snapshot I uploaded... (attached)

You can see that I started at the bottom, and 80 comes after 79 as it should, but is followed by another 80, then two 82s, an 83, an 85, and an 86. Not exactly right. Very helpful tool though! TY

This is from the Sandstorm app store, I am running my own on-premises instance and it is using the Sandstorm-for-Work LDAP support and keeps updated with new releases from the app store, but that probably is mostly irrelevant information except for the version of Annotate I am using, which is 1.3.1.

[simonv3]

Weird! This is very possibly because of some latency between the server and the front-end and Meteor just going ahead and creating new things before the previous element has been saved. Is it still a problem on page refresh?

[yebyen]

It is weird. This one (from the second image I annotated... first image had "1" and "2" dots as you'd expect, second image looked like this)...

This is after a page refresh, definitely. The app grain has had time to spin down and start up again.

How does a triage for an issue like this work in Sandstorm, can you send me an updated version and I try it on just my server? Or do you push out a new version when you think you found the problem, and everyone gets it...

I'm hoping that you can push out an update that will fix my grain, as it was quite a lot of work annotating nearly 100 machines! ;)

[simonv3]

I could send you an updated version, but annotate is pretty low on my list of things to work on this summer - I've been pretty busy and foresee me continuing to be so. If I get a chance over the next few weeks I might be able to work on it, but I can't make any guarantees.

Of course, I'm more than happy to review code changes and such if anyone wants to go ahead and do a PR for this.

I think what needs to happen is that the app needs to prevent creating a new annotation when an annotation hasn't received a response from the server yet. The logic for a single-reference point of what the current increment is needs to be better.

Packaging it up and releasing a version onto Sandstorm I can definitely do without a problem.

I don't know whether your annotations will be fixed with just an update though - I suspect that those numbers are there to stay. It used to be that numbers were just based on index within the array of annotations, but that changed because there was a request for being able to delete annotations and having the reference numbers stay the same. It's possibly a good idea to also add functionality to just update the actual value of a number. The question is - do those have to be unique? Probably not, as long as they're consistent in how they get created the user should be able to edit and rename them to whatever they want.

[yebyen]

Ok. I will be moving to a new state at the end of this week, so I feel you
on the being too busy thing.

I can take a stab at figuring out how to do the fix when I land though,
maybe some time next week!

Thanks for the quick feedback and good suggestion.

On Wed, Jul 27, 2016, 1:57 PM Simon notifications@github.com wrote:

I could send you an updated version, but annotate is pretty low on my list
of things to work on this summer - I've been pretty busy and foresee me
continuing to be so. If I get a chance over the next few weeks I might be
able to work on it, but I can't make any guarantees.

Of course, I'm more than happy to review code changes and such if anyone
wants to go ahead and do a PR for this.

I think what needs to happen is that the app needs to prevent creating a
new annotation when an annotation hasn't received a response from the
server yet. The logic for a single-reference point of what the current
increment is needs to be better.

Packaging it up and releasing a version onto Sandstorm I can definitely do
without a problem.

I don't know whether your annotations will be fixed with just an update
though - I suspect that those numbers are there to stay. It used to be that
numbers were just based on index within the array of numbers, but that
changed because there was a request for being able to delete annotations
and having the reference numbers stay the same. It's possibly a good idea
to also add functionality to just update the actual ID of a number. The
question is - do those have to be unique? Probably not, as long as they're
consistent in how they get created the user should be able to edit and
rename them to whatever they want.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#28 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-l7oqtI8SP4at3t4hN-e8MoEaXNMSxks5qZ5v3gaJpZM4JVlNS
.

[zeigerpuppy]

I'm not sure if this should be here or a different issue. Anyway, I noticed that when you delete an annotation, the number of the annotation is not available anymore. This is confusing as notes will not be in sequence anymore. For instance:

a. make note (1)
b. add another note (2)
c. delete note (2)
d. add another note - becomes (3) not (2)

This means that the notes shown are now (1) and (3). It would be good to have the option of renumbering notes or freeing up note numbers once a note is deleted.
The case of deleting an intermediate note is a bit more complicated.
Let's say we have notes (1).... (10).
Now I delete note (5). I would suggest a function that renumbers the remaining sequence from (1)....(9) would be useful.
Ultimately a simple note browser may be needed that allows reordering of note numbers.
I'd suggest a table with draggable rows would be a good solution, it would also make editing multiple note titles easier.