Fix auto-numbering (canonical sites, observations)

[phraenquex]

Number canonical sites:

descending order of number of unique compounds in canonical site.

Short code suffix:

number continuously within same canonical site.

Thus, these should have been A,B (or B,C).

Preserving short tags:

Front-end should always preserve the auto-assigned short-tag that the loader auto-generates. So:

• In F/E, when user edits tag, if the short code is overwritten, prepend it again upon save. (@boriskovar-m2ms)
• B/E should serve the short tag in the endpoint. (@kaliif)

[boriskovar-m2ms]

@kaliif so I assume there will be something like short_code for each tag retrieved from /api/siteobservation_tag/ endpoint. Correct?

[phraenquex]

@boriskovar-m2ms that's technically a different ticket, but yes, the short codes are held by the B/E.

@kaliif will need to confirm.

[boriskovar-m2ms]

@phraenquex is there ticket for that? Because I can see in this ticket that it's specified that B/E should serve the short tag in the endpoint. (@kaliif)

[phraenquex]

@boriskovar-m2ms please resolve directly with @kaliif. The short code is the absolute reference for everything, but I have no insight how it affects the code.

[boriskovar-m2ms]

@kaliif is it easy for generated tags to to contain attribute short_code which would contain the first part (before hyphen) of the auto-generated name? And null for custom tags.

Now the question is (I think this is also for @phraenquex @Waztom and @mwinokan ) that it would be better if the name of the tag (tag attribute in the data retrieved from /api/siteobservation_tag/) would contain (in the case shown in the picture above) just A301 and full name 1 - A301 would be assembled on the fly in the frontend. It will take slightly more time (couple of hours?) to implement BUT I think it will be much more cleaner and more safe and user will not even be able to edit the part before hyphen and frontend will not be required to try to detect if that part is missing or is changed etc. But we can also do it that way but the former would be a lot nicer to implement and later on understand.

[kaliif]

@boriskovar-m2ms, api/siteobservation_tag/ now serves two tag names, tag, and upload_name:

{
    "count": 63,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "site_observations": [
                40,
                61
            ],
            "tag": "1 - A301",
            "upload_name": "1 - A301",
            "create_date": "2024-03-04T14:15:19.802421Z",
            "colour": null,
            "discourse_url": null,
            "help_text": null,
            "additional_info": null,
            "category": 2,
            "target": 1,
            "user": null,
            "mol_group": 1
        },

If I understand you correctly, you're suggesting splitting the tag attribute into tag and tag_prefix, containing A301 and 1 respectively (and empty value for curated tags)?

[boriskovar-m2ms]

@kaliif Yes that would be ideal.

[phraenquex]

@boriskovar-m2ms on your question: yes, it sounds smart to keep the tag and tag_prefix separate.