@xhoenner and I just noticed that the option for users to specify the tag 'STATUS' in a dropdown menu is creating quite a few issues:
(1) As we understand, the way it works is that when a tag is first registered in the database its status will be as 'NEW'. After the same tag has been released the tag status will automatically change to 'DEPLOYED'.
However, when looking at some duplicate tags registered multiple times (https://github.com/aodn/aatams-content/issues/50) we noticed that users quite often change the tag status to DEPLOYED manually, not knowing about the automatic process described in (1). By users manually updating their tag status to DEPLOYED upon registering the tag, the automatic fill for tag details during the tag release process is also compromised (see #364).
Since (1) occurs naturally within the database there is no real need for users to be able to assign a tag as DEPLOYED themselves, especially as this has created additional issues for us to sort between correct and incorrect duplicate entries. It may be better to remove the STATUS dropdown menu and add a checkbox for each extraordinary case where the user might want to specify a change in a tag's status (e.g. LOST tag checkbox with a field for loss date)
Eventually merging the tag registration and release processes (#365) will get rid of all the issues mentioned above.
@xhoenner and I just noticed that the option for users to specify the tag 'STATUS' in a dropdown menu is creating quite a few issues:
(1) As we understand, the way it works is that when a tag is first registered in the database its status will be as 'NEW'. After the same tag has been released the tag status will automatically change to 'DEPLOYED'.
However, when looking at some duplicate tags registered multiple times (https://github.com/aodn/aatams-content/issues/50) we noticed that users quite often change the tag status to DEPLOYED manually, not knowing about the automatic process described in (1). By users manually updating their tag status to DEPLOYED upon registering the tag, the automatic fill for tag details during the tag release process is also compromised (see #364).
Since (1) occurs naturally within the database there is no real need for users to be able to assign a tag as DEPLOYED themselves, especially as this has created additional issues for us to sort between correct and incorrect duplicate entries. It may be better to remove the STATUS dropdown menu and add a checkbox for each extraordinary case where the user might want to specify a change in a tag's status (e.g. LOST tag checkbox with a field for loss date)
Eventually merging the tag registration and release processes (#365) will get rid of all the issues mentioned above.