Add ability to create, update, and delete TagCategories via APIv2

[IllyaMoskvin]

I need the ability to manipulate TagCategories via APIv2, when logged in as admins. TagCategories have no relationship to Projects, AFAICT, so there's no restriction in terms of cascading per-project permissions. Requires #323 first.

That does raise the question as to whether the TagCategories should be restricted per project.

[hburgund]

Tag Categories definitely should not be assigned to specific projects. I don't see any benefit and there is a lot of overlap i.e. almost all projects will utilize the "question" tag category.

As far as what you need, essentially, it sounds like you need standard POST/GET api/2/tagcategories/, yes? I guess you might need PATCH as well...?

I'm not sure I fully understand the relationship with #323, though. I get that logging in as staff would be required to access these api calls, but the api calls themselves aren't crafted any differently as a result, yes? I ask simply because I want to know if I can work on building the api calls prior to you figuring out #323!

[IllyaMoskvin]

Ah, that's right! I think we chatted about that aspect of Tag Categories before, and I believe you mentioned something similar at the time.

Yes, it's a pretty straight-forward implementation, I think. I'm not sure what should happen when a Tag Category that is being used by Tags is deleted. Should those tags set their category to null? Should the delete be stopped, if there are tags still referencing it? I'm not sure.

You're right, #323 will be required for the end-product, but I think the API calls can be implemented without it. All yours!

[hburgund]

Great; I will work on implementing the new api call ASAP.

Regarding Tag Category deletion, unless there is a reason not to do it this way, I would prefer to make any Tag Category currently being used by a Tag not deletable. That would force users to review all tags using that Tag Category prior to deletion. In reality, I doubt there will be much need to delete Tag Categories, so we could also just not offer this at all in the admin. I've literally never deleted a Tag Category.

[IllyaMoskvin]

Thank you! That sounds good to me, let's table deleting Tag Categories for later?

I figure, if we want to do it properly, for delete, we'll have to do a check on the backend to see if a Tag Category contains Tags, and if so, return an error code and message. We'll have to think whether to include the list of relevant Tags with the message, or if that logic will have to be handled on the client side.

I'll have to think about how to handle server-side error messages on the admin in the near future, but deferring Tag Category deletion for later will make it easier to reach an MVP.

[hburgund]

Yes, leave out delete for now; that is totally fine.

I'll keep you posted on my progress on this issue, but please let me know when it will become a blocker for you.