As it is right now, it is very tedious to add multiple terms to a vocabulary, because you have to add one term at a time, and each time requires a page load and an additional click to add another term (#1004). I did a bit of research, and the only ways that I found for adding multiple terms is either a) by importing CSV/XML files or b) using a text area instead of a text field.
IMO the import way is not suitable for core, but a simple UI would be a great addition. I looked at various modules like Taxonomy Batch Operations (only D4/5 versions and issues about porting to D6/7 that never flourished) and Manage Multiple Terms as well as the popular Taxonomy Manager and the way they do things while having in mind that if we are to get something into core, it'd have to be very minimal/simple. Here's a few ideas what I think might work...
1. Keep the current way of one term, one single term name text field.
2. Add a "Create multiple terms" button/link next to the the term "Name" text field that converts it to a text area (related?: #684). That text area would work the same way that the select list field form works (allows to add one value per line, in the format key|label): add values/entries one per line, in the format term_name|term_description|term_extra_field - the rest of the form settings (parent/URL alias) could apply to all terms entered in the text area.
3. If we need to specify different parents per entry, we could do what Taxonomy Manager does: Child terms can be prefixed with a dash -
(one dash per hierarchy level).
1. ...or we could use a similar UI/mechanism as Options Element:
These are and/or things that we could implement. They are not 100% original ideas and I have not come up with the perfect way to do it either - just saw the need and though that we could discuss/brainstorm and see if we can come up with something as good and the Layouts UI.
Recent comments
Hmmm, from D7 ancient tomes: from https://drupal.stackexchange.com/questions/7056/limit-which-roles-can-view-a-node-basing-on-its-content-type yet https://docs.backdropcms.org/api/...
node access
I also note on this screen: "Furthermore note that content which is not published is treated in a different way by Backdrop: it can be viewed only by its author or users with the...
node access
I am seeing via dpm debug that the nodes that are authored by someone else are not even being interrogated at the view level; they are simply avoiding the hook_node_access call. Yet the...
node access