Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Storm Attribute provides users with a means to set the options that appear for certain fields, and also the options that can be searched upon.
These prove quite confusing for a new user, so I propose that these should be moved to the admin settings for each module.
Comments
Comment #1
homoludens CreditAttribution: homoludens commentedI agree with and support this idea. if you need some help with implementing it and/or testing it - just say.
Comment #2
Magnity CreditAttribution: Magnity commentedThis isn't something i'll put much time into in the near future - so go ahead if you want to.
One thing I thought this could help especially is the relationship between the allowable values for a node and the values that are searchable. Currently, I think its a bit confusing as to how to choose which values are displayed for a particular search key.
Also, i'd be happy to implement this on a per module basis as long as we put some explanatory notes in the attributes section so that people know exactly whether a setting is a std setting or an attribute.
Comment #3
Magnity CreditAttribution: Magnity commented#652212: Proposal to remove distinct Storm Attribute permissions for a possible part of this.
Moving to D7, as I suspect that a lot of these changes will be helped by #293485: Integrate with CCK
Comment #4
juliangb CreditAttribution: juliangb commentedMoving 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.
Comment #5
juliangb CreditAttribution: juliangb commentedComment #6
juliangb CreditAttribution: juliangb commentedBelow 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.
Comment #7
tchurch CreditAttribution: tchurch commentedJust 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.
Comment #8
juliangb CreditAttribution: juliangb commentedSome 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?
Comment #9
Bill Lea CreditAttribution: Bill Lea commentedI'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.
Comment #10
juliangb CreditAttribution: juliangb commentedI like the idea of using taxonomies if it will do all / most of the things we want it to do.
Comment #11
Stolzenhain CreditAttribution: Stolzenhain commented+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).
Comment #12
zaffi CreditAttribution: zaffi commentedMultilingual and localization sites are not taken into consideration in Storm.
this is another reason why moving 'attributes' into standard drupal usage.
Comment #13
juliangb CreditAttribution: juliangb commentedHi @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.
Comment #14
Carsten Müller CreditAttribution: Carsten Müller commented+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:
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
- ...
Comment #15
juliangb CreditAttribution: juliangb commentedRetitling.
Comment #16
juliangb CreditAttribution: juliangb commentedMoving 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).
Comment #17
D34dMan CreditAttribution: D34dMan commentedThose 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.
Comment #18
juliangb CreditAttribution: juliangb commentedTrue - 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.
Comment #19
D34dMan CreditAttribution: D34dMan commentedYep 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.
Comment #20
juliangb CreditAttribution: juliangb commentedI 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.
Comment #21
D34dMan CreditAttribution: D34dMan commentedSo 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?
Comment #22
juliangb CreditAttribution: juliangb commentedLet's postpone until we've done the shift to Fields in core.
Comment #23
juliangb CreditAttribution: juliangb commentedAttributes won't exist in 2.x, they have been replaced by field values.