this certainly sounds like something that could be useful. I'll take a
look at it as soon as I can. I think my feeling is that as long as it
doesn't complicate other things too much it can probably go in. But
anyway, I won't say more until I've looked at it :) I'm sure Victor
will look at it too...
> now I've finished the work on the custom field groups / collections.
> The use of the collections are to groups custom fields together.
> So you can have e.g. field foo1, foo2 and foo3 and put them together in
> collection bar. Than you can add to your project bar and automatically
> you'll get foo1, foo2 and foo3 added. If you want to get rig of it -
> just delete bar and foo1, foo2 and foo3 are gone.
> When do you need that in real life?
> <tail tell time>
> Say you are a hardware company and keep track of
> reklamations in Mantis. And each of your products
> do have a serial number and a quality control guy
> associated to it who sent the product away.
> For each new product you'll create a new Mantis
> projects - and you are just binding one group (e.g.
> called product details) to it - and not 2 independant
> custom fields (serial number and quality control)
> So far there's not much saved work - only a bit
> better data organising.
> But now management comes and tells you that for all
> shiped products you must store the production date
> as well, when you get a reclamation...
> With custom field collections it's no problem - just
> add the new field to the "product detail" collection
> and every existing project has the new custom field
> as well (this might save you quite some time of
> stupid clicking...)
> So that's the basic stuff. Now we come to the real power of the new
> Since the production data is already in a
> database you want to save the poor guy in
> the reclamation department the task to look
> up the quality control guy and the production
> So you change the type of the collection to "database"
> and the guy gets a drop down list with all existing
> serial numbers - the rest is filled in
> automatically once the bug is submitted.
> How does it work?
> To link a collection to a database table, change
> Type -> database
> Data Source -> table name
> Data Column -> the column that contains the
> information that the user selects
> When you add custom fields to that collection you'll fill in the column
> name that get's filled in later.
> NOTE: You can fill in every table that the MySQL user that mantis uses
> has read access to. So when you are using the root user for that you
> are creating a security hole => check your permissions and check who's
> Mantis administrator!
> This is not a security hole by itself - but you have to be carefull!
> So another story why that's usefull:
> We use Mantis here at work as a helpdesk system and we've got all
> workers in a LDAP directory. So the person at the helpdesk only has to
> select the name of the person calling and department, telephone and
> email are automatically filled in.
> So I hope I could convince you that this feature is usefull and that it
> get's added to the official CVS tree - maintaining it seperately would
> be a real PITN.
> I tried to test every possible functionality and combination so it
> should be debugged...
Beta4 Productions (http://www.beta4.com)