i just tried setting up a 4.7 test site for the first time last night. when i enabled the projects module, i ran into a slightly confusing problem. when i went to create a project via node/add/project_project i was faced with a form area called "Categories" with a required drop-down box called "Projects" that had no elements in it. of course, when i tried to create a project, any attempt to preview or submit would fail, with the message:

"Projects field is required."

there was no other info about what was going wrong. after a few minutes of thinking about it, i realized what was going on. when i enabled project.module, it automatically created a new volcabulary for me (via _project_get_vid(), project.module ~ line 270). however, it (obviously) didn't create any terms in it. once i went to admin/taxonomy and edited the "Projects" volcabulary to add a new term, then the create project step worked fine.

i think this is confusing for site admins, and it seems like we could do a better job telling them what's going wrong in this (default) case. a few ideas:

  1. Is this really necessary? must we make the Projects volcabulary a required field for any project? what if i only want to setup 1 project? why must i define a category for it?
  2. (and this part might need to be moved into a separate issue for taxonomy.module, instead), if there's a required volcabulary for a given node type, and that volcabulary has no terms, instead of just displaying an empty dropdown box that is impossible to use, it'd be nicer to print out descriptive error message. something like:
    "ERROR: $type nodes require a term from the "$volcabulary" taxonomy volcabulary.  Unfortunately, that volcabulary has no terms to choose from.  Therefore, it is impossible to create a $type node until you define at least one term in the $volcabulary volcabulary.  You can do so at the (a href="admin/taxonomy/edit/volcabulary/$vid")edit taxomony(/a) page for this volcabulary.

    i intentionally used '(' in that url so folks can see exactly what i'm talking about, not some bogus link in this comment. in case it's not obvious, i mean "$volcabulary" to be the actual name of the volcabulary in question (in our case, "Project"), "$type" is the type of node that's requiring a term from this volcabulary, and "$vid" is the numeric volcabulary id for this volcabulary.

    if we were really kind, we'd do access checking and if the user didn't have permissions to create new terms in the volcabulary, instead of providing a link to a page they can't use, we'd say basically: "you can't create a $type node until a site administrator defines terms in the $volcabulary volcabulary... please contact the site admin about this" (or something).

i'm brand new to 4.7 drupal, so i don't really know where to start trying to make patches for any of this. i just wanted to post it here to get feedback before i dive in and try to provide a patch. please let me know if you think this is on the right track.

thanks,
-derek

CommentFileSizeAuthor
#12 -none-.png2.89 KBBojhan
#5 project_required_field.png47.17 KBmagico
#1 project-required-empty-taxonmy.png92.45 KBdww

Comments

dww’s picture

dww
we/he/they
commented
StatusFileSize
new project-required-empty-taxonmy.png92.45 KB

for the interested reader, here's a screenshot of what i'm talking about.

dww’s picture

dww
we/he/they
commented
Title: better error messages when there are no terms in the Projects taxonomy » better error messages when there are no terms in a required taxonomy
Project: Project » Drupal core
Component: User interface » taxonomy.module
Priority: Normal » Minor

as you can see from the original post, this started as something specific to the project module's use of an auto-generated, required taxonomy. that's been fixed as far as the project module is concerned (see http://drupal.org/node/60627 and http://drupal.org/node/64221). so, this issue is really a core taxonomy.module UI request at this point.

if there's a required taxonomy with no terms, instead of just presenting an empty dropdown or multiselect that's impossible to validate or use, it'd be nice to print the kind of error message i included in my original post. i have no time to work on a patch for this at the moment, but i wanted to move this issue to its proper resting place. ;)

thanks,
-derek

magico’s picture

magico commented
Category: bug » feature
Priority: Minor » Normal

I think this is a feature. Re-design those fields!

dww’s picture

dww
we/he/they
commented
Category: feature » bug
Priority: Normal » Minor

*sigh*

magico, i appreciate your desire to clear out the issue queues. however, it's starting to get a little annoying that you keep changing bug reports i've filed into feature requests. the behavior i describe is broken. fixing that broken behavior is not a "feature".

the broken behavior is somewhat obscure, which is why i submitted it as minor (which is what i'm setting it back to), but it's broken nonetheless...

please don't continue to reclassify bugs that you'd like to see fixed as feature requests. ;) that's not the point. if you want to be helpful, you could start writing the code to fix some of these things. ;)

thanks,
-derek

magico’s picture

magico commented
StatusFileSize
new project_required_field.png47.17 KB

A big issue is *not* the place to question someones work, because it will make the issue off-topic. If you have something to say about someone's work, you can contact them or evaluate their work through a posting on the mailing list.
I've choosed one path. After reviewing, clearing, making detailed reports, contacting personally some authors to clarify issues, making real patches for posted code for about 600 (yes, six hundred) issues it's natural that being human I make mistakes.

On topic:
1. tried to download "Project" HEAD. It's normal still not working for HEAD
2. download and install projet.module for 4.7
3. goto ?q=admin/settings/project an save as is
4. ?q=node/add/project_project
5. submited without problem (after verified that the module indeed had reated a "Projects" vocabulary)
6. ?q=admin/taxonomy/add/vocabulary
7. add a new (Projectos) required vocabulary for "project" node type, but I do not add any term to it
8. ?q=node/add/project_project again
9. I try to submit it but it tells me that the "category" is required as shown on the attached screenshot

So AFAIK, the first submission worked nice! And it only asked for the required vocabulary after I've associated a new category.

After this I though "well there is no bug, but it would be nice to have a diferent message because the default one is to obscure"... also I thought "the ideal was that if a required vocabulary has not terms it should not be used during node creation/editing".

Finally both your point 1 and 2 are sugestions to a change in the currently behaviour and would never be a bug fix but adding a new feature.

And you at the #2 say it all

if there's a required taxonomy with no terms, instead of just presenting an empty dropdown or multiselect that's impossible to validate or use, it'd be nice to print the kind of error message i included in my original post.

Am I wrong, maintaing my opinion that this is a feature request?

I just ask you: please be fair with your judgments.

magico’s picture

magico commented

(note: sorry for my english, because of it I tend to be short and incisive with my reports)
A big issue = An issue
contact them = contact him
evalute their = evaluate his

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Project module actually doesn't have much to do with this bug. You can also see this bug if you try to create a forum topic without first having created forums, afaik.

dww’s picture

dww
we/he/they
commented

magico: my deepest apologies for offending you. you're right, you're on fire cleaning up the issue queues in general, and i love you for it.

i was only reacting to the fact that i've now run into about 3 or 4 of my bug reports that you came upon, bothered to spend the time reading and thinking about them (which is great) but drew the conclusion that the request to fix the bug is really a feature request. that's all i was commenting about -- the 4 of my personal issues you did this to, not the 596+ other issues you've worked on. ;)

on topic:
1) i never, ever claimed i was porting the TRUNK of project to work with the TRUNK of core. it's not documented to work, and it doesn't work. ;) furthermore, it won't work until after the new release system is done and in place (http://drupal.org/node/77562) as that is my absolute top priority.

2) as i described (when i moved this issue from project into core), this bug is now impossible to see with project nodes, because i added a work-around via http://drupal.org/node/60627 and http://drupal.org/node/64221.

3) re: Finally both your point 1 and 2 are sugestions to a change in the currently behaviour and would never be a bug fix but adding a new feature. -- this gets to the heart of the disagreement. *every* bug fix is a "change in the current behavior". if your definition of a "feature" is "changing current behavior", *nothing* would ever qualify as a *bug fix*. so, yes, i think your wrong in this case. ;) let me explain...

currently, if you define a required taxonomy for a given node type, but add no terms, then:
- it is impossible to add nodes of that type
- it is very difficult to understand why, since the UI is so broken

that's a bug, straight up. it needs to be fixed. "changing this behavior" is not a "feature". ;)

that said, it's a *MINOR* bug. :) most admins aren't going to be this dumb. it doesn't happen on a default drupal install -- you already have to go out of your way to define a required taxonomy. so, this isn't urgent. but, it's a bug nonetheless.

also, just because the core committers might decide to only fix a bug in the TRUNK (the misnamed "cvs" version), doesn't mean it's a feature. a bug is a bug. some bugs require such massive changes that fixing them in the middle of a stable series is too risky, and it's better to just leave it broken (ideally, documented as a known bug) and fix it in the next development series. other bugs are so minor that it's not worth the trouble/risk to back-port them. but, that's a completely separate discussion over whether it's a bug or a feature.

anyway, sorry for the length post about what makes a bug a bug and a feature a feature, but i hope it's taken as constructive feedback on your highly valuable efforts to clean up the issue queue... i'm sorry i was too brief in my post #4, and that it came across as a personal attack. not at all my intention...

please, keep up the good work, but keep this discussion in mind as you do it. ;)

thanks!
-derek

ricabrantes’s picture

ricabrantes commented
Version: x.y.z » 7.x-dev
Component: taxonomy.module » forum.module

this bug still alive in D7.x-dev, when try to create a forum topic without first having created forums..

brianV’s picture

brianV commented

Not something easily accomplished.

This field is currently caught by the _form_validate() function, which, in it's own words:

/**
 * Performs validation on form elements. First ensures required fields are
 * completed, #maxlength is not exceeded, and selected options were in the
 * list of options given to the user. Then calls user-defined validators.
 *

In order to do what is suggested, we would need to somehow bypass the standard validation entirely for this field, and set up a special validation for it.

dww’s picture

dww
we/he/they
commented
Component: forum.module » taxonomy.module
Issue tags: +Usability

This isn't specific to the forum module, and marking this as a usability bug.

Bojhan’s picture

Bojhan commented
Status: Active » Fixed
StatusFileSize
new -none-.png2.89 KB

Seems Fields fixed this.

-none-.png

Status: Fixed » Closed (fixed)
Issue tags: -Usability

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +Usability

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.