Improve "index" handling

[jasollien]

After communication with Solibri, we see the need to improve how "index" is specified in BCF-API documentation.

1. Index should be a floating number, to make it easier to reorder topics
2. Index should be assigned server side if omitted
3. Index should be rebalanced by the server periodically to avoid floating number overflow. Example ("1, 1.5 2", should be transformed to "1, 2, 3")
4. Index should not be visible for end users?

Would be nice to discuss this at todays telecon

[pbuts]

As also indicated in #201, there are already implementation that treat the index as an server generated immutable, project unique number to identify topics.

BIMcollab uses the index this way. We could generate a user friendly Id conform #201 from this number, but for compatibility with existing implementations, I would propose not to change this property but instead add another way of defining a sort order.

Changing any issue property would also change it's modification timestamp and I would not want a sorting order change to change all may topics.

Thus for user defined sorting maybe an additional endpoint is needed that would only carry a list of issue identifiers in the sort order wanted. This would also be much faster on projects with lots of topics as otherwise each individual topic would have to be modified

[ykulbak]

summary of the discussion today:

• Index on topics is deprecated and would be removed in a future release. The use of index to identify topics is replaced by server_id
• Comments to that effect should be added to both the BCF-XML and BCF-API documentation.
  @pasi-paasiala

[ykulbak]

Closed by #244

[AlainBolduc]

Hi guys, I know this issue is closed, but I'd like to raise the fact that by replacing an integer / float by a string will most likely introduce some sorting issues. Moreover, in previous versions, the client could specify the index, and now it has become a server ID.

Relying solely on the server will introduce some strange sorting behaviors in situations where the client would try to simultaneously perform some POST requests. In this case, the sorting of the issues can be altered and cannot be "controlled" by the client.

What will be the expected behavior in this case?