Bug 427907 - XMLRPC function getCompInfo
XMLRPC function getCompInfo
Status: CLOSED NEXTRELEASE
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
3.2
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: Noura El hawary
:
Depends On:
Blocks: RHBZ30UpgradeTracker 406131 427053
  Show dependency treegraph
 
Reported: 2008-01-07 21:03 EST by Noura El hawary
Modified: 2013-06-24 00:17 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-18 16:38:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
new WebService module (1.73 KB, text/plain)
2008-01-13 01:18 EST, Noura El hawary
no flags Details
perl test script of the map function and $_ (547 bytes, application/x-perl)
2008-01-13 12:52 EST, Kevin Baker
no flags Details
New bugzilla module with functions to get component info (3.12 KB, text/plain)
2008-01-14 23:50 EST, Noura El hawary
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 385282 None None None Never

  None (edit)
Description Noura El hawary 2008-01-07 21:03:27 EST
write xmlrpc function getCompInfo that is to be contributed to the upstream.
Please refer to the following url for details on Bugzilla::RPC 2.18 functions mapped to upstream Bugzilla::WebService and for 2.18 xmlrpc functions sorted by percentage of calls: https://engineering.redhat.com/trac/bugzilla-3.0-rh/wiki/XmlrpcCrossComparison#a2.18xmlrpcfunctionssortedbypercentageofcalls
Comment 1 Noura El hawary 2008-01-13 01:18:24 EST
Created attachment 291488 [details]
new WebService module 

as discussed with upstream ,, it is preferable that we have a WebService module
called Component.pm to hold all the component xmlrpc functions. one thing they
use is components and products ids as function arguments, in our version of
xmlrpc we use names I believe it is more user friendly, but using id is safer
as product and components names might change , just as how we encountered
before some issue when changed the name of product SV3 to EIT. I have written
an initial function that takes a list of component ids and returns the
component information. one problem in the attached patch is the following line:


initial_cc => [map $_->{login_name},  @{$_->initial_cc}],

the usage of $_ will create errors as each $_ refers to different value. I
wasn't sure how to solve this issue .. Any suggestions?

also we can easily change this function to receive list of product names and
component names instead of ids. it will work the same as the component object
can be instantiated either using component id or hash with product name and
component name.
Comment 2 Kevin Baker 2008-01-13 12:51:11 EST
> one problem in the attached patch is the following line:
> 
> 
> initial_cc => [map $_->{login_name},  @{$_->initial_cc}],
> 
> the usage of $_ will create errors as each $_ refers to different value. I
> wasn't sure how to solve this issue .. Any suggestions?

That should work as is. Did you test it? I think perl does the right thing. 
Read `perldoc -f map`

       map BLOCK LIST
       map EXPR,LIST
               Evaluates the BLOCK or EXPR for each element of LIST 
              (locally setting $_ to each element) ...

Comment 3 Kevin Baker 2008-01-13 12:52:46 EST
Created attachment 291508 [details]
perl test script of the map function and $_

Test script for the map function to prove that it will local'ise $_ for each
map.
Comment 4 Noura El hawary 2008-01-14 20:17:57 EST
Hi Kevin,,

I think the test you attached will work fine and also 
initial_cc => [map $_->{login_name},  @{$_->initial_cc}], 

on its own will work fine but ,, the problem i found with my patch was that
every time i call the function it will produce a different output ,, I think
that the reason that everytime it runs the order of the hash key will be
different and the values of $_ in the above line will get confused as the following:

       map {{
               id          => type('int')->value($_->id),
               name        => type('string')->value($_->name),
               description => type('string')->value($_->description),
               product_id  => type('int')->value($_->product_id),
               product_name     => type('string')->value($_->product->name),
               default_assignee   =>
type('string')->value($_->default_assignee->{login_name}),
               default_qa_contact =>
type('string')->value($_->default_qa_contact->{login_name}),
               initial_cc => [map $_->{login_name},  @{$_->initial_cc}],

             }
        } @components_objs;


so maybe key default_assignee got processed after the key initial_cc then the
value of  $_->default_assignee->{login_name} will not be from @components_objs.

what do you think?

Thanks,
Noura
Comment 5 Noura El hawary 2008-01-14 20:51:48 EST
hmmm ,, Kevin I retested it today and it looks like it is working fine, there
must've been something wrong before .. It looks good now. 
Comment 6 Noura El hawary 2008-01-14 23:50:49 EST
Created attachment 291677 [details]
New bugzilla module with functions to get component info

The attached patch now has 2 xmlrpc functions :

1-Component.get => gets the components info by a list of its ids
2-Component.get_by_name => gets single component info by its component and
product name. 

Noura
Comment 7 Kevin Baker 2008-01-15 17:07:15 EST
1) nice looking code

2) get_by_name assumes that the user always supplies a valid product & 
component combination. error handling?

3) Any reason for limiting get_by_name to only return on product/component 
combination? why not an array or product/components? If you go that route then 
you could reuse the code from 'get'.

4) Lastly, if WebService::Bug has get_bugs what should WebService::Component 
have? ;)

Kev
Comment 8 Noura El hawary 2008-01-15 23:36:13 EST
(In reply to comment #7)
> 1) nice looking code
> 
> 2) get_by_name assumes that the user always supplies a valid product & 
> component combination. error handling?
> 
> 3) Any reason for limiting get_by_name to only return on product/component 
> combination? why not an array or product/components? If you go that route then 
> you could reuse the code from 'get'.
Yeah I thought about that , I will change it to accept a list of hashes instead
of single hash.

> 
> 4) Lastly, if WebService::Bug has get_bugs what should WebService::Component 
> have? ;)
I think that mkanat said that they would want to change get_bugs in Bug.pm to
get and he was saying that we would create in Component.pm also a function
called get(), I refer to that from: 

https://bugzilla.mozilla.org/show_bug.cgi?id=385282#c7

Noura

> 
> Kev

Comment 9 David Lawrence 2008-01-15 23:50:15 EST
I have always thought it should eventually be a simple API like Bug.get()
Bug.create() and Bug.update(). Same for Component, etc.
Comment 10 Noura El hawary 2008-01-21 23:58:10 EST
LOC estimation:

Inputs: hasref with ids/(component-product names) = 1
Outputs: input validation errors, logging messages,
         hashref with components info = 3
Inquiries: component data , user data, product data = 3
Logical files: noneero
External files = Zero

FP total count(simple weighting factor)= (3*1)+(4*3)+(3*3)+(7*0)+(5*0)= 25

FP = 25 * 1.11 = 28

LOC = 28 * 60 = 1680


For Unit testing:

100 LOC for one xmlrpc testcase

total LOC = 1680+100 - 1780 LOC

Comment 11 Noura El hawary 2008-01-29 11:07:05 EST
added code to force returning only components info for products that the user
can access. also added POD section and did few little modifications that were
suggested by upstream. submitted new patch version to the upstream for review.
Comment 12 Noura El hawary 2008-02-25 11:32:25 EST
made some modifications to the function code Component.get(), moved the code to
return accessible unique component objetcs from passed component ids or
component/product names to a separate subroutine to make it usable for other
functions.
Comment 13 David Lawrence 2008-03-18 16:33:40 EDT
This feature is included now in Milestone 2. Any bugs found with this feature
should be file as a new report and set to block the 3.2 final release tracker.

Note You need to log in before you can comment on or make changes to this bug.