[drupal-devel] [bug] New field type for profile: taxonomy

[budda]

Issue status update for 
http://drupal.org/node/19014
Post a follow up: 
http://drupal.org/project/comments/add/19014

 Project:      Drupal
 Version:      cvs
 Component:    profile.module
 Category:     bug reports
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  wiz
 Updated by:   budda
-Status:       active
+Status:       patch (code needs review)
 Attachment:   http://drupal.org/files/issues/profiletaxonomy.patch (4.78 KB)

Attached is my patch against profile.module in HEAD as of today
(14/09/2005).


As I have developed the changes against a live 4.6.3 website I've not
got any way to test the changes against a Drupal HEAD install. 


The patch includes all code changes originally submitted by wiz.
However it doesn't include the changes/additions to the database
definition files (they can be found in
http://drupal.org/files/issues/profile-taxonomy-2.patch).


First patch against Drupal core code. Hopefully it wont be too shabby.




budda



Previous comments:
------------------------------------------------------------------------

Wed, 16 Mar 2005 22:09:00 +0000 : wiz

Attachment: http://drupal.org/files/issues/profile-taxonomy.patch (3.87 KB)

A new type of field in the profile: taxonomy, useful for a field to
select zero or more terms from a vocabulary.  This works like the type
"selection" but multiple selection is possible, and the list of choices
comes from a taxonomy.  Unfortunately there is no field in the table
profile_fields to store single/multiple selection - which would be nice
for the type "selection", too.


The selection is stored in a new table (profile_values_term)
additionally to the column profile_values.value.  This allows for easy
processing of the selection the user made.  I have not defined any
indexes on this new table, which possibly would be required for large
data sets.


It has a small bug: when nothing is selected, it will automatically
select the first entry.  The fix would probably have to modify
_taxonomy_term_select in taxonomy.module.




------------------------------------------------------------------------

Wed, 16 Mar 2005 22:16:53 +0000 : moshe weitzman

please set issues to patch once they have been tested. the patch queue
is not a place for changes which have known bugs. thanks.




------------------------------------------------------------------------

Wed, 16 Mar 2005 22:26:02 +0000 : wiz

ok thanks for the hint ;)  my third post...




------------------------------------------------------------------------

Thu, 17 Mar 2005 06:52:24 +0000 : wiz

Attachment: http://drupal.org/files/issues/profile-taxonomy-2.patch (4.58 KB)

Updated patch with the following fixes:



* index on table profile_values_term 
* table creation also for Postgres 
* handling of selection of no terms 

I don't see any bugs left at the moment.




------------------------------------------------------------------------

Mon, 25 Jul 2005 17:18:34 +0000 : budda

+1  Works for me.




------------------------------------------------------------------------

Wed, 14 Sep 2005 16:17:13 +0000 : budda

>From the patch I noticed some issues:


(1) When viewing a users profile, the profile_view_field() function
does not support 'taxonomy' $field->type so nothing is displayed on the
?q=user/2 page.


(2) When editing a users profile which has a taxonomy field, the term
selection is always showing as a scrollable HTML select list. This
happens even if the vocabulary is not set to 'multiple select'. A
scrollable list takes up much more page space than a drop down select
menu so i think it should be changed to operate based on the vocabulary
setting. This can be achieved with taxonomy_form() rather than going
directly to _taxonomy_term_select(()


(3) There is no suport for browsing profile's by clicking on the
taxonomy. profile_browse() needs to support the $field->type 'taxonomy'
still.


(4) More generally I also noticed that profile.module 4.6.3 and HEAD
both uses same hacked up query building rather than passing everything
through as printf() style parameters.


I've fixed all of the above in my profile.module now. I'll compile a
patch against HEAD soon and submt it.