New types for Manual Metric?

[Johannes Zink]

Hey guys,

are there any plans to provide more types for Manual Metrics?
Our sonar users requested:
-Link (in our case a report stored on another system)
-Date
-Enum (predefined selection of options to choose)

Any thoughts on that?

Regards

[Johannes Zink]

No thoughts so far??

[Fabrice Bellingard-4]

Hi Johannes,

There's no plan for such feature. Actually, we don't have much feedback about manual measures, which tends to tell that this feature is not that useful. Maybe you can share your use cases with us? 

On Tue, Apr 28, 2015 at 11:06 AM, Johannes Zink <[hidden email]> wrote:

Hey guys,

are there any plans to provide more types for Manual Metrics?
Our sonar users requested:
-Link (in our case a report stored on another system)
-Date
-Enum (predefined selection of options to choose)

Any thoughts on that?

Regards



--
View this message in context: http://sonarqube.15.x6.nabble.com/New-types-for-Manual-Metric-tp5034808.html
Sent from the SonarQube Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Johannes Zink]

Hi Fabrice

Thanks for the response.

Let's see if I can explain the use case properly :)

Our IT security department tests our projects for security flaws and creates security-reports.
Every project is analysed with SonarQube so they want to save the link to the related security report in SonarQube as well.
Additional information like "Pentest date", "Pentest findings", etc. should also be saved.

We created some Manual Metrics for them to save the information. The suggested types (link, date, enum) currently are of type "Text". Enum-type would be some kind of preselection to choose from, e.g. low, med, high. (Sounds pretty tricky to me...)
New types would be "nice to have".

This is where my question kicks in :)

Regards,
Johannes

[Fabrice Bellingard-4]

Thanks Johannes for sharing this with us.

I understand your use case, but I don't think that manual metrics are the good way to handle it. The information you want to store can't be considered as a "metric":

• you can't make a measure filter based on a URL for instance
• such info (a vulnerability report) should be linked to a specific snapshot whereas manual measures are just "blindly" propagated from one snapshot to the next one

, so in fact using the "manual metric" feature to achieve what you want would be a hack. 

More generally, everything in SonarQube is designed around the source code itself, so every information that one wants to store in SQ should be linked to some source/test file. The black box approach of security tests makes this impossible, so such reports are difficult to integrate in SQ. And "manual measures" should not be used for that.

On Mon, May 4, 2015 at 3:08 PM, Johannes Zink <[hidden email]> wrote:

Hi Fabrice

Thanks for the response.

Let's see if I can explain the use case properly :)

Our IT security department tests our projects for security flaws and creates
security-reports.
Every project is analysed with SonarQube so they want to save the link to
the related security report in SonarQube as well.
Additional information like "Pentest date", "Pentest findings", etc. should
also be saved.

We created some Manual Metrics for them to save the information. The
suggested types (link, date, enum) currently are of type "Text". Enum-type
would be some kind of preselection to choose from, e.g. low, med, high.
(Sounds pretty tricky to me...)
New types would be "nice to have".

This is where my question kicks in :)



--
View this message in context: http://sonarqube.15.x6.nabble.com/New-types-for-Manual-Metric-tp5034808p5034949.html

Sent from the SonarQube Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[fge]

Hello,

On Tue, May 5, 2015 at 4:50 PM, Fabrice Bellingard
<[hidden email]> wrote:

>
> Thanks Johannes for sharing this with us.
>
> I understand your use case, but I don't think that manual metrics are the good way to handle it. The information you want to store can't be considered as a "metric":
>
> you can't make a measure filter based on a URL for instance
> such info (a vulnerability report) should be linked to a specific snapshot whereas manual measures are just "blindly" propagated from one snapshot to the next one
>
> , so in fact using the "manual metric" feature to achieve what you want would be a hack.
>
> More generally, everything in SonarQube is designed around the source code itself, so every information that one wants to store in SQ should be linked to some source/test file. The black box approach of security tests makes this impossible, so such reports are difficult to integrate in SQ. And "manual measures" should not be used for that.
>

But then, when exploring the source a little, I see that a MetricDef
has methods {get,set}Data(); is this something which is to be removed
or is this for something else entirely?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Johannes Zink]

You got a point there and I agree with you! The information can't be considered as a "Metric" and it's not a good way to handle the use-case, but sadly it's currently the only way. :(
Some users can be very persistent to get what they want (even by misusing other features)... Especially the ones with power.

Okay, no new types for Manual Metrics. :)

Some quick thoughts: What do you think about a feature to add notes/information to a project?
Again, it's information that is not directly linked to source/test file.
But, I can image that there are some use-cases for this (besides mine). E.g. if I want to store the name of the product owner on a project. :)

Fabrice Bellingard-4 wrote

Thanks Johannes for sharing this with us.

I understand your use case, but I don't think that manual metrics are the
good way to handle it. The information you want to store can't be
considered as a "metric":

   - you can't make a measure filter based on a URL for instance
   - such info (a vulnerability report) should be linked to a specific
   snapshot whereas manual measures are just "blindly" propagated from one
   snapshot to the next one

, so in fact using the "manual metric" feature to achieve what you want
would be a hack.

More generally, everything in SonarQube is designed around the source code
itself, so every information that one wants to store in SQ should be linked
to some source/test file. The black box approach of security tests makes
this impossible, so such reports are difficult to integrate in SQ. And
"manual measures" should not be used for that.


Best regards,

*Fabrice BELLINGARD | SonarSource*
*SonarQube Platform Product Manager*
http://sonarsource.com

[Fabrice Bellingard-4]

This won't be removed. This is used internally to store information that is more complex than just an integer or a boolean - like the complexity distribution for instance. Such metrics can't be used in measure filters but still they are always specific to the snapshot they are attached to.

On Tue, May 5, 2015 at 6:21 PM, Francis Galiegue <[hidden email]> wrote:

Hello,

On Tue, May 5, 2015 at 4:50 PM, Fabrice Bellingard
<[hidden email]> wrote:
>
> Thanks Johannes for sharing this with us.
>
> I understand your use case, but I don't think that manual metrics are the good way to handle it. The information you want to store can't be considered as a "metric":
>
> you can't make a measure filter based on a URL for instance
> such info (a vulnerability report) should be linked to a specific snapshot whereas manual measures are just "blindly" propagated from one snapshot to the next one
>
> , so in fact using the "manual metric" feature to achieve what you want would be a hack.
>
> More generally, everything in SonarQube is designed around the source code itself, so every information that one wants to store in SQ should be linked to some source/test file. The black box approach of security tests makes this impossible, so such reports are difficult to integrate in SQ. And "manual measures" should not be used for that.
>

But then, when exploring the source a little, I see that a MetricDef
has methods {get,set}Data(); is this something which is to be removed
or is this for something else entirely?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Fabrice Bellingard-4]

On Wed, May 6, 2015 at 11:23 AM, Johannes Zink <[hidden email]> wrote:

You got a point there and I agree with you! The information can't be
considered as a "Metric" and it's not a good way to handle the use-case, but
sadly it's currently the only way. :(
Some users can be very persistent to get their features... Especially the
ones with power.

Okay, no new types for Manual Metrics. :)

Some quick thoughts: What do you think about a feature to add
notes/information to a project?
Again, it's information that is not directly linked to source/test file.
But, I can image that there are some use-cases for this (besides mine). E.g.
if I want to store the name of the product owner on a project. :)

You might know (or not!) that you can add some links to "document" your project. Some links are populated with information from your Maven POM or sonar-project.properties file, and some are free to be set by project admins:

Those links are displayed in the "Description" widget.

From my point of view, this is the place where you can link your project to the central place where all the information related to your project is gathered. In most IT department, there's such a central place in order to prevent info duplication and therefore save time & energy when you have to update this info.

 

Fabrice Bellingard-4 wrote
> Thanks Johannes for sharing this with us.
>
> I understand your use case, but I don't think that manual metrics are the
> good way to handle it. The information you want to store can't be
> considered as a "metric":
>
>    - you can't make a measure filter based on a URL for instance
>    - such info (a vulnerability report) should be linked to a specific
>    snapshot whereas manual measures are just "blindly" propagated from one
>    snapshot to the next one
>
> , so in fact using the "manual metric" feature to achieve what you want
> would be a hack.
>
> More generally, everything in SonarQube is designed around the source code
> itself, so every information that one wants to store in SQ should be
> linked
> to some source/test file. The black box approach of security tests makes
> this impossible, so such reports are difficult to integrate in SQ. And
> "manual measures" should not be used for that.
>
>
> Best regards,
>
> *Fabrice BELLINGARD | SonarSource*
> *SonarQube Platform Product Manager*
> http://sonarsource.com





--
View this message in context: http://sonarqube.15.x6.nabble.com/New-types-for-Manual-Metric-tp5034808p5035039.html

Sent from the SonarQube Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Johannes Zink]

Yes, I found this earlier today :)
Thank you.

[Michel Pawlak]

Hi Fabrice,

By the way it would be great if it was possible to create/read/update/delete these links via the webservice API. Indeed with lots of projects and multiple links it's a real pain to maintain these links and there is no way to read them.

Would it be possible to create a ticket in order to add such a feature ?

Thanks in advance,

Michel

[Fabrice Bellingard-4]

Hi Michel,

=> http://jira.codehaus.org/browse/SONAR-6541

On Wed, May 6, 2015 at 5:40 PM, Michel Pawlak <[hidden email]> wrote:

Hi Fabrice,

By the way it would be great if it was possible to create/read/update/delete
these links via the webservice API. Indeed with lots of projects and
multiple links it's a real pain to maintain these links and there is no way
to read them.

Would it be possible to create a ticket in order to add such a feature ?

Thanks in advance,

Michel



--
View this message in context: http://sonarqube.15.x6.nabble.com/New-types-for-Manual-Metric-tp5034808p5035064.html

Sent from the SonarQube Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email