Change attributes into taxonomy

I agree with and support this idea. if you need some help with implementing it and/or testing it - just say.

Moving back to D6. This will simplify the D7 port anyway.

I have a few ideas of how to do it now and will try a patch once 1.34 is released.

Below is a list of domains used in Storm attribute. I believe the settings should be in different places according to domain.

Also, I am thinking of removing the functionality to have 'active' and 'inactive' attributes. My view is that if you want something inactive, you remove it.

Country:
Surely this is something that a number of Drupal modules would use. I would consider shipping this out to an external module. Addresses module does this, and has a function _addresses_country_get() (addresses.inc) that returns an array of countrycode => name as Storm attributes currently does. If we did introduce a dependency on addresses, we may be able to use that module to handle some of the fields in Storm later too. Country is used in the stormorganization module only.

Duration unit (hour / day):
This is currently only used to store 'hour' and 'day'. I wonder about hardcoding these. Does anybody use anything else but 'hour' and 'day'? It is used in stormproject, stormtask, and stormticket - so should probably be defined in storm.module or stormproject.

Price mode
Used in stormorganization, stormproject, stormtask, and stormticket. Perhaps move to storm.module general settings.

Knowledgebase topic
Expense status / Expense status search
Project category / Project category search / Project priority / Project priority search / Project status / Project status search
Task category / Task category search / Task priority / Task priority search / Task status / Task status search
Ticket category / Ticket category search / Ticket priority / Ticket priority search / Ticket status / Ticket status search:
All of these are just used in one module, so can be moved as separate settings there.

Just a few comments:

1) Countries
I must admit that every time I create a new install of Storm on a Drupal site, it's a pain to keep making all the not-needed countries to 'inactive'.
It might be better to have all countries inactive by default and then allow users to activate the one(s) they want.

2) active/inactive
I find it useful to keep records in the table as inactive for 2 reasons:
a) I can see what was there and re-activate easily if needed
b) With things like price modes and statuses, if they have been used previously, removing them might cause problems displaying those projects/tasks/tickets later.

Some good points there. It will not simplify it as much as I wanted to, but it sounds like the active/inactive is actually needed.

Any thoughts on the other ideas?

I'm new to the Storm system and I find the attributes quite confusing. How are they different from Taxonomies? Why not use taxonomies instead of a new system which looks like a taxonomy but has a much more difficult administration page. I mean there are ten pages out of the box and I can think of dozens of term I need to define my particular needs.

I like the idea of using taxonomies if it will do all / most of the things we want it to do.

+1 taxonomy usage
This would really make management/integration for new users much easier. A good example of taxonomy integration into module functionality was Ubercart, allowing for usage of many other structural tools without being dependent on Ubercart core (aside from Views usage).
The only argument against fields would be the flexibility of Views (fields are easier to process in Views, as far as I know), but in the long run, it seems much more consistent (f.e. during transitions from similarly structured Drupal sites to Storm and back).

Multilingual and localization sites are not taken into consideration in Storm.
this is another reason why moving 'attributes' into standard drupal usage.

Hi @zaffi, can you be more specific about the problems for multi-lingual sites? Feel free to open new issues if less related to this one.

+1 for taxonomy

i think it is easier to handle and better for multiple languages.

Is it needed to separate the status for tasks, projects and tickets and to have a second attribute for the filters?
That are 6 different attribute types.

So, what is really needed:

• Country
• Duration unit
• Price mode
• Priority
• Project category
• Task category
• Ticket category
• Status

This will make 8 different taxonomy vocabularies.

Another advantage of taxonomy is the possibility to use the hierarchy. Especially the countries can be divided by the continents
- Asia
- Japan
- China
- ....
-Europe
- England
- France
- Germany
- ...

Retitling.

Moving to Project Management queue.

We should keep an eye on this in the pre-beta stage (outcomes will probably depend on how we proceed with conversion to Field API).

Those list fields that take option value through attributes could be made to use Term fields. So integration wouldn't be as difficult.

Those who feel they can't live without inactive attribute, can install termstatus, i have not tried it but it seems to do the job.

True - but another thought that occurred to me was do we need all domains of attributes in taxonomy, or could some be part of a standard list field?

Country field, for example could be entirely replaced by the list within the Addressfield module, and I wonder if the same can be done elsewhere too.

Yep that is the easiest. It gives a really intuitive interface to manage the options too. But then inactive won't be available any more.

I am not sure though which allowed values declaration would take precedence, the one declared in code ( field api ) or the one in settings form.

I assume that for most fields, the values declared in code could be overridden by the settings form - a positive for customisation as long as it doesn't break any functionality.

So in short there won't be any patch for this issue i assume. Unless there are attributes which are never used by any fields. Are there any?

Let's postpone until we've done the shift to Fields in core.

Attributes won't exist in 2.x, they have been replaced by field values.