413770 - update WebService function Bug.get() to enable user specifying bug attributes that they want

Status: RESOLVED FIXED

(Bugzilla :: WebService, enhancement)

Description

[Noura Elhawary]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070417 Fedora/2.0.0.3-4.fc7 Firefox/2.0.0.3
Build Identifier: 

currently WebService Function Bug.get() returns stable bug details which are: 
'creation_time', 'last_change_time', 'id', 'summary', 'alias' 
and then there is the unstable section which is 'internals' which basically returns the bug object. basically information like bug groups, keywords, comments are not returned by the current Bug.get(), our redhat version of Bug.get() returns those sort of information and it is heavily used within the company. We would like do few changes to Bug.get() that would make it more flexible. one idea was to pass another hash key "optional" to Bug.get which will point to an  attributes array that contains all the attributes that the user would like to get, something like this attributes => ['groups', 'comments', 'keywords'] , "field mapping can be used here just how it is done in Bug.create" so the design will be :

if $params->{attributes} is defined 
   then return the stable section of the Bug.get() + the passed attributes
else
   return the stable section of the Bug.get() + the curent internals section

One more thing is that we also have a function that returns the bug activities, not sure if you would prefer that we incorporate this function into Bug.get so the user can pass in the $params->{attributes} list value 'activity' or if this is too much and the function GetBugActivity in Bugzilla::Bug is not an instance accessor so maybe we can have it as a separate function called Bug.get_activity.

I will attach a patch that can make my explanation clearer. 

Please let me know what you think.

Thanks,
Noura

        


Reproducible: Always

Comment 1

[Noura Elhawary]

Attachment: v1 for changes to WebService::Bug::get() and new function WebService::Bug::get_activity()

patch for the previous comment

Comment 2

[Max Kanat-Alexander]

Comment on attachment 298842 [details] [diff] [review]
v1 for changes to WebService::Bug::get() and new function WebService::Bug::get_activity()

The reason attributes aren't returned by Bug.get is because we weren't sure what format to return them in.

Most attributes (the basic ones that aren't arrays from other tables) should always be returned.

Here's the thing to think about:

Now that we have custom statuses and resolutions, does returning just a string mean anything? What about their sortkeys? What about all of the different information associated with a Status? Probably what we need to do is add functions for getting info about statuses and resolutions, etc. (but in a different bug, after this).

Comment 3

[Max Kanat-Alexander]

Also, don't make two changes in one bug--you added get_activity in this patch and that should be in a separate bug.

Comment 4

[David Lawrence [:dkl]]

(In reply to comment #3)
> Also, don't make two changes in one bug--you added get_activity in this patch
> and that should be in a separate bug.
> 

One idea we had been talking about which may be why this is combined in a single bug is that bug activity could just be another attribute of a bug report. So if you want to see the activity for a bug report then simple call

Bug.get({ ids => [413770], attributes => [..., 'activity'] });

Then there would be an additional key in the data returned called 'activity' or 'bugs_activity', etc that would be data structure with the bug changes. It could be in a list of attributes or just pass the single attribute 'activity' which would equivalent to Bug.get_activity().

Yet another way to keep the number of methods down to a minimum. Thoughts?

Dave

Comment 5

[Noura Elhawary]

Hey Max,, How about that we take show_bug.cgi as a standard for what should be returned. So in show_bug.cgi basically users see statuses and resolutions as strings right? they don't need to see sortkeys and other info. what do you think? I guess the format to be returned will be different between different attributes but it will still depend on the information we want to return , but if it will be treated differently then the code will need to be more complex caze we will have to write separate code for each attribute.

Comment 6

[Frédéric Buclin]

Fixed by bug 573195. The bug activity is obtained separately by Bug.history.