From: <Chr...@he...> - 2003-01-21 12:51:09
|
From: ju...@be... [mailto:ju...@be...] > > > Think of the way currently the "Select Profile" is handled. You can > > select a profile and it'll automatically fill in the values for the > > "Platform", "OS" and "Version" - but it won't store what you've > > selected in the "Select Profile" field. > > Ok, but how would you implement the Profile case? If we can find a > flexible way to implement that case then it should work for > your case. > If we implement stuff only in terms of LDAP, we still can't > achieve the > Profile case. With the collections you can implement a "Profile" like solution. You are adding a new database table to MySQL and let the collection do the work to extract the data from there. What I need is exactly like that - only that the data comes through LDAP. But there's no real difference here, only the low leve APIs called. So all we need is to mimic the Profile case with custom fileds to make me happy. (Except the pages used to enter the profile data itself; we can think of the data as being externally provided and administerd, every thing else is far too much problem specific) > > I also don't know if it's easy to write a function that > changes other > > values outside of that function. > > Possibly not very, it is kind of ugly. We could - but that means a big Mantis rewirte - stuff all the data input from a form into an assoziative array. This array is passed to our custom function which will return a modified version. I.e. we won't have $c_category, $c_status, $c_severity, ... anymore and we are using $c_data['category'], $c_data['status'], $c_data['severity'], ... instead > > > > As I wrote earlier I think the combination is very > powerfull. We give 2 > > default ways (Database and Ldap) for the most often used > cases as well > > as the custom functions for total freedom (but also more > implementation > > work) > > Hmm.. I guess I beter look at your patch again then. But although I > think some kind of solution is a good idea here, I'm going to oppose > adding too much complexity for it. This may just be one of > those cases > where so much flexibility is needed that we just can't > provide a system > that provides enough and still remains reasonably easy to configure. Have a look at my example in the message where I wrote about the collections. There you can see some very powerfull stuff you can do with it. And I think together with the custom functions we've got an extremely powerfull system as both fit together very well. > > I'm not vetoing anything yet. I still want the other > developers to jump > in and give their opinions (anyone out listening out there?) > and I need > to look over the patch again and we need to keep discussing > it. Yes, Please!! That I don't know how to resolve the 2 remaining issues with custom functions doesn't mean that there's no sollution, so please make your suggestions! > I'll get > back to you as soon as I have time to stufy your patch in more detail. ok, great. At the latest I'll be able to respond on next monday... I hope that we can get a sollution till 7. Feb (or so) as I'm able to work a short period on Mantis full time and then I want to switch our company data over to the new function. > > As written above: if we find sollutions for the 2 last > remaining issues > > on my side it can be a great alternative and it'll do what > I need. But > > currently *I* can only think of a bad kludge for the first > issue (store > > in the database if a custom field should be shown or not) and no > > solution at all for the second issue. > > You may be right that it is a bit kludgy for that case. I > can't really > focus on this problem as I find it a bit broad - hopefully > someone else > can throw in some useful input. Only try a way to mimic the "Profile" behavior with the custom fields (you can limit yourself to the dabase case; the ldap case is very similar and I'll be able to extend it then). That's all I need... CU, Christian |