-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature request] tags for Acronyms #124
Comments
@nanometrenat i've addressed some of this idea, starting with the easier things.
These two were relatively easy solutions that just required adding a couple columns to the acronym table, migrating that change to production, and updating the models and Flask routes that handle reading/writing data. I have not implemented the tagging as this involves much more overhead with new many-to-many relationships, which in turn means new tables to handle those relationships. It also means that unlike the scope and country above which have either very simple lists (former) or an existing table to reference (latter—the All this to say, this is half done and ready for your review. The other changes I list above will require me to carve out more brainspace and time. |
Thanks, that's great to have at least the two key things that will make it easier for users to see. There's one more core scenario that we need to figure out simplest plan for. Perhaps "Place" or "Geographic" as an extra dropdown under scope? This is to cater for the following types of acronym:
Thanks |
Hello hello! Loving the new scope + country being on the add/edit pages. Should I log a separate ticket to request these fields be visible on the View acronym pages too?
@katherinelilly not sure if this has become a thing for someone else these days or still JG - but tagging in case. THANK YOU! |
Hi there, following the work done for #109 and the conversation in Slack, please may you kindly introduce the concept of "tags" for the acronyms.
This means people will be able to see at a glance what the acronym relates to - e.g.
It's fine for the tags to be fairly free-form - as we tried imposing a hierarchy when doing the initial analysis and several things fell into multiple categories in the hierarchy.
Aware this is build - and there are various design options - so super-happy to talk about options that balance level of effort to implement vs maintain.
cc @ioalexei @toffehoff
The text was updated successfully, but these errors were encountered: