449161 - op_sys and platform should be custom fields with an extension for auto-selecting

Status: NEW

(Bugzilla :: Extensions, enhancement, P3)

Description

[Max Kanat-Alexander]

According to the Bugzilla Survey (which will be published in the next few days, once I finish compiling all the data and writing it up), the single *most* common problem is that the op_sys or platform fields aren't applicable to what the users are doing with Bugzilla.

To solve this, we should make op_sys into a custom field, called cf_os or something like that, and rep_platform info a custom field called cf_platform.

We should include a disabled plugin that does the "match the browser's OS and platform" trick that we have now.

We should upgrade current installations that have op_sys and platform to change them to custom fields. We should not add them to new installations, but enabling the plugin and running checksetup should add them.

Comment 2

[Marc Schumann [:Wurblzap]]

See also bug 160572.

Comment 3

[Max Kanat-Alexander]

I'm taking this, as it was the most-requested item in the survey.

Comment 4

[Vitaly Fedrushkov]

Why should we rename fields?  Is there anything special in treatment of cf_* fields?

This was discussed back in 2002: all fields -- besides primary keys and those used in workflow -- are effectively 'custom', i.e. serve no other purpose besides entry, search and reporting.

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> Why should we rename fields?  Is there anything special in treatment of cf_*
> fields?

  Yes, a fair bit. All custom fields must be named cf_*.

> This was discussed back in 2002: all fields -- besides primary keys and those
> used in workflow -- are effectively 'custom', i.e. serve no other purpose
> besides entry, search and reporting.

  That's a bit of a narrow view--Bugzilla isn't just a framework for making a bug tracker, it's actually a bug tracker. So it does need certain fields with a certain layout and so on. But it's true that a lot of the functionality can be made generic, which is what we hope to do.

Comment 6

[Max Kanat-Alexander]

Attachment: Work In Progress

Here is just the code required to migrate the fields and create them on new installations if they don't exist. (The idea behind creating them automatically on new installations is so that we can preserve backwards API compatibility in the WebServices, and also to have a certain set of fields that are always in Bugzilla but can be disabled very easily.)

Comment 7

[Kevin Brannen]

Max,

I was thinking about adding a few flags like "userepplatform" and such, but this is a much better solution. I see a patch here. Can I apply that to a 3.2.3 or 3.4.1 install and use it? (Or do I need to pull off of a specific CVS branch?) What is still missing, since it's a WIP? What still needs to be done that I can work on and submit a patch to take it further? :)

Thanks,
Kevin

Comment 8

[Max Kanat-Alexander]

Hey Kevin! Well, basically everywhere in Bugzilla that uses "op_sys" and "rep_platform" has to be changed to use cf_os and cf_platform, with inserting some backwards-compat into the webservice and search URLs. Then you have to do bug 307688 (basically make that code into a plugin). Also, we need to have the "allow custom fields to have a default" feature (in another bug).

Comment 9

[Kevin Brannen]

(In reply to comment #8)
> Hey Kevin! Well, basically everywhere in Bugzilla that uses "op_sys" and
> "rep_platform" has to be changed to use cf_os and cf_platform, with inserting
> some backwards-compat into the webservice and search URLs. Then you have to do
> bug 307688 (basically make that code into a plugin). Also, we need to have the
> "allow custom fields to have a default" feature (in another bug).

Wow! This is bigger than I originally imagined. :) Still, maybe I can do some parts of it and generally speed up the work so this makes it into BZ 3.6.

It looks like I'd need to do bug 351899 first (defaults for custom fields), then the generic version of 307688 to make all custom fields work correctly, then finally the transition code that's actually referenced here.

So, I'll create a 3.4.1 install and start working on 351899. If you think this plan is not correct or you have other advice, please let me know.

Comment 10

[Max Kanat-Alexander]

(In reply to comment #9)
> It looks like I'd need to do bug 351899 first (defaults for custom fields),

  That sounds right.

> then the generic version of 307688 to make all custom fields work correctly,

  Well, all we need is for that to move into a plugin that looks for fields named "cf_os" and "cf_platform" and fixes them appropriately if they have no default.)

> So, I'll create a 3.4.1 install and start working on 351899. If you think this
> plan is not correct or you have other advice, please let me know.

  Work against HEAD, not 3.4.1.

Comment 11

[Frédéric Buclin]

We no longer accept new features for Bugzilla 3.6. Retargetting to 3.8.

Comment 12

[Frédéric Buclin]

Any progress? :)

Comment 13

[Kevin Brannen]

I work on this during my spare time, which I'll admit has not been much lately. My real problem is that the database modification part is about as clear as mud to me. Even looking at the suggested patches from older releases hasn't helped me much. I think I could change all the CGI parts without any problem if I could figure out how to do the DB part.

Is there an easy way to do that?

Comment 14

[Max Kanat-Alexander]

Basically the DB part is just a bunch of bz_rename_column and bz_rename_table stuff, and then some modifications to the fielddefs table.

Comment 15

[Frédéric Buclin]

mkanat, any chance to have it for 4.2?

Comment 16

[Max Kanat-Alexander]

(In reply to comment #15)
> mkanat, any chance to have it for 4.2?

  Mmm, it's not really my focus right now, but it was one of the most-requested survey items. Once I get through the Search.pm work and we get closer to releasing 4.0, I'll have a better idea of what I can do for 4.2. Right now, I can't say.

Comment 17

[Frédéric Buclin]

Comment on attachment 373283 [details] [diff] [review]
Work In Progress

>+sub _convert_to_custom_field {

>+        $dbh->do('UPDATE fielddefs SET name = ?, custom = 1 WHERE name = ?',
>+                 undef, $new, $old);

You first have to make sure $new is not already in use. Someone could have already created a custom field named cf_os or cf_platform. It would be great if we could have some reserved syntax for "hardcoded" custom fields, e.g. hcf_os and hcf_platform (h meaning hardcoded).

Comment 18

[Frédéric Buclin]

(In reply to Frédéric Buclin from comment #17)
> You first have to make sure $new is not already in use. Someone could have
> already created a custom field named cf_os or cf_platform. It would be great
> if we could have some reserved syntax for "hardcoded" custom fields, e.g.
> hcf_os and hcf_platform (h meaning hardcoded).

hcf_* would also let us easily implement bug 9412 comment 63 without having to worry if cf_type or similar is already in use or not.

Comment 19

[Max Kanat-Alexander]

I don't really want to add some other custom field name format. It's often been convenient that custom fields have only a single naming format. Perhaps if there's an existing field with the hardcoded name, just rename it.

Comment 21

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 22

[[e-mail]]

for those using Bugzilla to anything not related to sw developemtn, it is still important enhancement:)

Comment 23

[Frédéric Buclin]

I'm going to implement bug 763409 first, which is much easier to do.