Re: RE : [Mantisbt-dev] New feature proposal: test sheet management

[Julian Fitzell <julian@be...>]

Ludovic, I'll reply in more detail later but I think this sounds like a 
good idea and I think it can be made to work pretty easily.

Julian

ludovic.roux@... wrote:
> Hi Julian,
> 
> I work with Jean-François Travers, and I participated
> in the development of the test sheet addition to Mantis.
> 
> 
>>>I did not have the time to take a look at the new "custom field" feature
> 
> but
> 
>>>maybe we could use it to declare a 'test' field in bug reports ? If we
> 
> could
> 
>>>proceed this way, that would be great since it would probably save us
>>>modifying all these files ! We have one constraint, which is that this
>>>'test' field is not just a free text field, but a link towards a record
> 
> in
> 
>>>another table.
>>
>>What do you mean by 'a link towards a record in another table' ?  Would 
>>Christian's custom field grouping stuff help here?  Mostly, I forget 
>>what exactly you needed to store or point to for the test 
>>sheet stuff - 
>>I'm not sure I ever quite understood it.
> 
> 
> First, an explanation about the links between tests and bugs.
> We develop a large software with many functionalities for a client.
> To make sure the software complies with the specifications,
> a test plan is defined in cooperation with our client.
> The same test plan will be passed on the software on our side
> and on our client's side. If a tester detects a bug or a strange
> behaviour while trying to perform let's say TEST 15, then he
> writes a new bug report with a reference to TEST 15.
> 
> The display of the bug should contain a field for the related
> test name (TEST 15). In fact, this field is a clickable link
> to test sheet "TEST 15".
> 
> Reciprocally, when you display a test sheet, the list of bugs
> linked to this test are displayed. We display bug id, and it is
> a link to the page displaying the bug.
> 
> 
> It is our duty to deal with the link to bug page when displaying
> a test sheet.
> 
> But we have to modify the view_bug_page to display the link
> to the related test sheet.
> 
> ------
> 
> OK, after this long explanation, go back to Christian's custom field
> to handle our test sheet name in the bug page.
> 
> Custom fields are really well adapted to handle test sheet name,
> but they lack something to handle this name as a link to another page.
> More generally, they lack a way to retrieve and process data from
> other mantis tables before displaying the custom field value.
> 
> To make custom fields more general (and to make them an ideal
> solution for our "link to another page" problem),
> we would like to propose this modification to custom fields:
> 
> - add field "function" to mantis_custom_field_collection_table
> function varchar(128)
> "function" field will contain the name of a function to be called
> for specific processing needing additional information
> not provided by custom field.
> In our case, custom field will store a test sheet id.
> Our function to be called has to look in mantis_test_sheet_table
> for the name corresponding to test sheet id,
> then an anchor to view_test_sheet_page is generated.
> 
> We think this processing is too much specific to be put in
> print_custom_field_collection_input.
> The solution of storing a function to be called for such
> specific processings is more appropriate.
> 
> 
> - add a "case CUSTOM_FIELD_TYPE_FUNCTION" to
> print_custom_field_collection_input
> and print_custom_field_collection_output functions.
> This case has to call the function read from field "function"
> of mantis_custom_field_collection_table.
> The called function should receive a parameter to tell if the
> call comes from print_custom_field_collection_input
> or print_custom_field_collection_output.
> 
> 
> 
> 
> But there is still a question.
> Question: Is it possible in PHP to call a function
> stored as a string in a variable?
> 
> Of course, custom fields API has to include
> the files defining all the specific functions.
> 
> 
> 
> In conclusion, custom fields are a powerful way
> to make Mantis easily extensible while preventing
> modifications on mantis bug core code.
> But ideally we would like custom fields to be able to call
> external functions.
> 
> 
> Sorry for a so long mail.
> 
> Regards,
> 
> 	Ludovic ROUX
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> Time is running out!  Thinkgeek.com has the coolest gifts for
> your favorite geek.   Let your fingers do the typing.   Visit Now.
> T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> _______________________________________________
> Mantisbt-dev mailing list
> Mantisbt-dev@...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev


-- 
julian@...
Beta4 Productions (http://www.beta4.com)

RE : [Mantisbt-dev] New feature proposal: test sheet management

[<ludovic.roux@fr...>]

Hi Julian,

I work with Jean-Fran=E7ois Travers, and I participated
in the development of the test sheet addition to Mantis.

> > I did not have the time to take a look at the new "custom field" =
feature
but
> > maybe we could use it to declare a 'test' field in bug reports ? If =
we
could
> > proceed this way, that would be great since it would probably save =
us
> > modifying all these files ! We have one constraint, which is that =
this
> > 'test' field is not just a free text field, but a link towards a =
record
in
> > another table.
>=20
> What do you mean by 'a link towards a record in another table' ?  =
Would=20
> Christian's custom field grouping stuff help here?  Mostly, I forget=20
> what exactly you needed to store or point to for the test=20
> sheet stuff -=20
> I'm not sure I ever quite understood it.

First, an explanation about the links between tests and bugs.
We develop a large software with many functionalities for a client.
To make sure the software complies with the specifications,
a test plan is defined in cooperation with our client.
The same test plan will be passed on the software on our side
and on our client's side. If a tester detects a bug or a strange
behaviour while trying to perform let's say TEST 15, then he
writes a new bug report with a reference to TEST 15.

The display of the bug should contain a field for the related
test name (TEST 15). In fact, this field is a clickable link
to test sheet "TEST 15".

Reciprocally, when you display a test sheet, the list of bugs
linked to this test are displayed. We display bug id, and it is
a link to the page displaying the bug.


It is our duty to deal with the link to bug page when displaying
a test sheet.

But we have to modify the view_bug_page to display the link
to the related test sheet.

------

OK, after this long explanation, go back to Christian's custom field
to handle our test sheet name in the bug page.

Custom fields are really well adapted to handle test sheet name,
but they lack something to handle this name as a link to another page.
More generally, they lack a way to retrieve and process data from
other mantis tables before displaying the custom field value.

To make custom fields more general (and to make them an ideal
solution for our "link to another page" problem),
we would like to propose this modification to custom fields:

- add field "function" to mantis_custom_field_collection_table
function varchar(128)
"function" field will contain the name of a function to be called
for specific processing needing additional information
not provided by custom field.
In our case, custom field will store a test sheet id.
Our function to be called has to look in mantis_test_sheet_table
for the name corresponding to test sheet id,
then an anchor to view_test_sheet_page is generated.

We think this processing is too much specific to be put in
print_custom_field_collection_input.
The solution of storing a function to be called for such
specific processings is more appropriate.


- add a "case CUSTOM_FIELD_TYPE_FUNCTION" to
print_custom_field_collection_input
and print_custom_field_collection_output functions.
This case has to call the function read from field "function"
of mantis_custom_field_collection_table.
The called function should receive a parameter to tell if the
call comes from print_custom_field_collection_input
or print_custom_field_collection_output.




But there is still a question.
Question: Is it possible in PHP to call a function
stored as a string in a variable?

Of course, custom fields API has to include
the files defining all the specific functions.



In conclusion, custom fields are a powerful way
to make Mantis easily extensible while preventing
modifications on mantis bug core code.
But ideally we would like custom fields to be able to call
external functions.


Sorry for a so long mail.

Regards,

	Ludovic ROUX

Re: RE : [Mantisbt-dev] New feature proposal: test sheet management

[Julian Fitzell <julian@be...>]

jean-francois.travers2@... wrote:
> Hi Julian,
> 
> Jeroen suggested a few days ago to make our test sheet feature an optional
> one thanks to a new configuration variable. That would be easy to do as far
> as software code is concerned. Nevertheless, we will still need new tables
> and new fields in the database ...
> 
> I was telling you in my initial proposition that we had to modify about 25
> existing files in Mantis core delivery. That's what makes it difficult to
> keep up with the current Mantis implementation. But we can distinguish three
> categories among these files:
> 
> - files that are anyway modified in the scope of Mantis user customization:
> 
> constant_inc.php
> config_inc.php
> config_defaults_inc.php
> strings_english.txt
> 
> Nothing much to do about these files, I think ...
> 
> - files that we had to modify because we introduced a new field in
> mantis_bug_table:
> 
> bug_report_page.php
> bug_report_advanced_page.php
> bug_report.php
> ...
> 
> It seems quite difficult to move this additional code into other files. 
> 
> I did not have the time to take a look at the new "custom field" feature but
> maybe we could use it to declare a 'test' field in bug reports ? If we could
> proceed this way, that would be great since it would probably save us
> modifying all these files ! We have one constraint, which is that this
> 'test' field is not just a free text field, but a link towards a record in
> another table.

What do you mean by 'a link towards a record in another table' ?  Would 
Christian's custom field grouping stuff help here?  Mostly, I forget 
what exactly you needed to store or point to for the test sheet stuff - 
I'm not sure I ever quite understood it.

> - api files in which we have added new functions related to our new table in
> database for test sheets (mantis_test_sheet_table):
> 
> string_api.php
> current_user_api.php
> helper_api.php
> email_api.php
> print_api.php
> filter_api.php
> bug_api.php
> ...
> 
> We have decided to modify these files because assuming that our test sheet
> functionality would have been integrated in Mantis official delivery
> (optional or not), we thought the code would in this way be much more
> readable and therefore maintainable. For instance, we added in
> filter_api.php a filter_get_test_sheet_rows function which is the equivalent
> for test sheets of the filter_get_bug_rows that is implemented in that same
> php file. If we had not hoped that our feature would be integrated, we would
> probably have put this function and all the others in our new
> test_sheet_api.php file in order to make easier the merges between our
> Mantis implementation and Mantis official deliveries. In fact, besides
> bug_api.php (and still because of that new field we introduced in
> mantis_bug_table), I think we could avoid modifying all the other api files.

Yes, I would think that much of this code could be in one custom API 
file.  I mean honestly, filter_geT_bug_rows() may not be the best name. 
  The filter_api is really just a subset of the bug_api but we've split 
it up because there is a logical boundary there and it's nice to keep 
the bug_api from getting too big.  There's nothing wrong with having a 
testsheet_api that does something similar.

> Anyway, it is obvious that your efforts to have a cleaner API do help a lot
> when introducing such evolutions ...
> 
> - files like set_project.php we had to modify because we added a new section
> in Mantis cookie. When cookie cleaning is needed, I don't think we can avoid
> to add at least one statement for our own section. But I think this file
> contains an example of code that could be enhanced to make Mantis developers
> life easier (the big "if" statement that allows to redirect to the 'same
> page' when switching projects).

Yes, that is horrid, ugly code... not sure exactly why it needs to be 
there.  I'm pretty confident we can come up with a better solution - 
like always pass in the page to redirect back to?

> To sum up, I would say that when we add a new table in Mantis database, it
> is quite easy to put the related software code into new files that are not
> present in Mantis core delivery. Merging our evolutions with new Mantis
> deliveries is then very simple. It is much more difficult when we add a new
> field in an existing table: the number of impacted files can become quite
> large ... But maybe custom fields are the solution ?

Well, yes, I think that is all very accurate.  When you add a field to 
an exiting table, you'll likely have to modify code that deals with that 
table.  When you add a new table, you write new code and only have to 
modify code in the places where there are relations between the tables.

The theory behind custom_fields is certainly that they are the solution 
to this kind of problem.  Though, primarily, they were designed to 
remove the slew of feature requests calling for the addition of new 
fields to the bug table.  Theses requests always involve the addition of 
the field, adding the field when displaying the bug, adding the field 
when editing the bug, when reporting the bug, when generating the query 
to update the bug, and so on.  The question is, now, are they powerful 
enough to allow more interesting uses of custom fields that require 
custom actions to be taken, computations to be done on their values, etc.

If you have time to look at the custom field stuff and see how it would 
fit with what you need, we'd appreciate it.  Feel free to ask for 
pointers if you need guidance while trying it out.

Julian




-- 
julian@...
Beta4 Productions (http://www.beta4.com)