Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001650TestLinkNew Featurepublic2008-07-30 22:162017-04-27 05:13
Reportervlada 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.7.4 
Fixed in Version1.8.5 (bug fixing) 
Summary0001650: Using Custom fields for TestPlan assignment for manage test automation data
DescriptionIt would be nice to have custom fields avaliable on panel for assignment of TestCases to TestPlan.

In my company we are thinking of customizing TestLink for automatic test execution. For this, it would be very convenient to have fields like 'Start time', 'Frequency', 'End time' and 'Script timeout'. They should be specified at the time of TestCase assignment.

Even better would be to get custom fields to display/enable on TestCase assignment
panel, and then add 'cfield types' for assigning datetime values.

Our script would then read database, select scheduled tasks and execute them at given time, submiting results back to TestLink.
Additional InformationIf you have ideas how to do this better, I am open for suggestions.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Files

- Relationships
related to 0001680closedfman Custom fields to be used on Test plan design (testcase assignment to testplan) 
related to 0000056acknowledged [SF 825060 ] Automated Test Integration 
related to 0007857new Enhance configuration support at test plan level 

-  Notes
(0003885)
fman (administrator)
2008-08-05 00:40

One issue:
value for this custom fields must be tied to Test Plan where test case is linked.
(0003888)
vlada
2008-08-05 00:57

yes. there will have to be new table holding values for assignments (something similar to cfields_execution_values)

but, these are implementation details. what do you think of the general idea - does it work with your design? is there a reason why it should not be implemented like this ? :-)
(0003895)
fman (administrator)
2008-08-05 13:56

1. Implementation details are not last thing to understand at least IMHO, because normally has side effects.

2. Think is better if we design a new table that will hold automation test case data, instead of trying to solve this using Custom Fields.

We need to focus on problem.
What is this problem:

1. having specific automated executing data for test cases, and may be for test suites ?

OR

2. having custom fields on assignment, that will be used when ? on execution
manually or not.

If we need both features, then please create two different issues.

I will give you more feedback in a few days
(0003903)
vlada
2008-08-05 18:57

Well, my company shall be using these features to implement automated TestCase execution, and I believe it will work fine in my case. But I'm not convinced that some generic automated testing that would cover all platforms could be added. For example, our TestCase scheduling is MS Windows dependent and it requires that NetBios protocol exists on network. (it is important for providing testcase scripts, retrieving test specific data, accepting testcase results and for testcase execution)

  Also, it will require significant amount of network tweaking and setup that we can easily do on our network, but in 'Generic Case' there should be tools that would do this in user friendly maner (network diagnosis and configuration). All this raises complexity of changes that should be introduced into main branch. So I'm not for implementing full test automation.

  But, on the other side we can make custom fields powerful enough that they can give infrastructure needed for integration of various automated test execution environments.

This is what I had in mind:

 - Custom Fields should be used during TestCase design (there we can use CF to get name of script that will be executed when we want to check if TestCase is valid or not)

 - Custom Fields shall be used for test scheduling (they will be used on frame rendered with 'tc_exec_assignment.tpl'), there we will specify when TC will be executed.

 - Custom Fields should be used on test execution to accept results of test script

_________________________
Example: I'll use StarTrack Enterprise TestProject for this example. Let us say we want to check if star ship computer is valid during the period ship is docked to DeepSpace9 station. So we create series of TestCases that verify if computer is running normally:

 TC1: We ping Enterprise ship to see if communication can be established (here we verify that OSI layers 1&2 are working well).
 TC2: We create connection to Enterprise database and verify information available on crew members. We check if minimum crew requirements are met for operating level 8 starship.
 TC3: We check various logs of sensory equipment to see if ship had behaved well on journeys between dockings to DeepSpace9.

 To execute each TestCase we need to be able to:
 1. We create Custom field named 'Script to execute' of type string. This field will be displayed/enabled only during TestCase design.

 2. When TestCase is designed we provide information on which scripts should be executed (so for TC1 we set 'Script to execute' to "class8ship/tc_ping_enterprise.sh"; for TC2, we set 'Script to execute' to "class8ship/tc_crew_requirements.pl"; and for TC3: we set it to "class8ship/tc_check_logs.pl")

 2a. It would be logical to group all these TestCases into 'Test Class 8 Ship Computer' TestSuite.

 3. We create Custom Fields 'Start date/time', 'End date/time' and 'Frequency'. These custom fields should be seen only during testcase execution assignment.

 3. Next we create TestPlan 'Enterprise Computer Check'. There we add all testcases TC1, TC2 and TC3. Then we assign these TestCases for execution, here we specify that we want TC1 to be executed every other day when Enterprise is docked on DeepSpace9 (say - if we know that Enterprise will be docked from 15. december to 15. january of 4093) then we set 'Start date/time' to be equal to "15. dec 4093 13:00"; 'End date/time' should be set to "14. jan 4094 13:00"; and 'Frequency' to "every 2 days".
   For TC2 let say we want it to be executed every week so we set 'Start date/time' to "15. dec 4093 00:00"; 'End date/time' to "14. jan 4094 00:00"; and 'Frequency' to "every Sunday";
   For TC3 we set to be executed only once (when ship has docked to DeepSpace9) so we set 'Start date/time' to "15. dec 4093"; 'End date/time' to "anything"; 'Frequency' to "execute once".

 4. Custom Fields named 'Test case results:' type 'URL' should be created. It should be seen only on TestCase execution.

 5. When tests are executed - results are submitted back to TestLink. So each of test scripts should renders HTML report. TC1 creates HTML report containing table of ping latency times for 10 ICMP packets. TC2 creates elaborate HTML report on each crew member and ship requirements. TC3 creates HTML report summarizing starships logs.

  After execution we (lets say - use Perls WWW::Mechanize module) submit our results back to TestLink specifying if test has Succeeded, Failed or Blocked. Standard error stream of each test is sent as comment to TestCase execution. We transfer each of our HTML reports back to TestLink server. (say we use FTP protocol and send it to some default class8 starship upload directory)
  
  Then we send exact URLs to uploaded HTML reports for each testcase. So that end user (DeepSpace9 commander) can see each testcase execution and access HTML report easily (with single click on testcase execution frame.

~~~~~~~~~~~~~~~~~~

  I hope use case scenario is now a bit clearer. If you have more questions feel free to contact me.

 Best regards,
 Vlada
(0003904)
fman (administrator)
2008-08-05 19:08

Thanks for the details.
I will try to read carefully and give you some feedback
(0003915)
vlada
2008-08-05 22:12

It would be very helpful if you could provide me with new database table names (their structure) and names of PHP classes/files that should be changed.

Thanks in advance,
Vlada
(0003919)
fman (administrator)
2008-08-05 23:40

Reminder sent to: mhavlat

I would like to know your ideas about this.
I will try to write down mine.

have a nice holiday
(0003922)
mhavlat (reporter)
2008-08-06 04:32

Thanks for your use case. I must remember, that we need to stay simple and universal. I try to draft my expectation before we fit this use case.

1. I miss information about current state of automation support in 1.8. The only I know that TCs have status auto/manual. Francisco, please, correct me if I'm wrong.

2. We could easily extend our API, so any script can ask and receive information about custom fields or other data for any object.

3. TestLink should be able to initiate a running of test script from GUI. So there should be a generic class that could generate an action via appropriate protocols or running a OS command. Syntax must be maximally configurable. (not your case)

4. I do not expect that we need to store testing scripts in our DB in this phase. Later of course, we can.

Back to the case.
Now I expect, that you have some cron initialization of script for periodical running. This script should be able to get all data via API (based on test plan ID).
I do not think that we need a new table for your case. CFs for TC within TPlan is enough. Then the next task are required:

1. Define a new CF type (for TC in TPlan) and update create CF definition page (and help).
2. Implement a new page for CF assignement. I think that TC assignment page is already too full of functionality (no more features here).
3. Extend API functions.

Waiting on Francisco's review.
(0003923)
mhavlat (reporter)
2008-08-06 04:44

Maybe, you should consider:
- feature: send a log for a test execution via API and save as attachment
- set CF "precondition test case" to allow check chain dependencies (hmmm, we can implement it directly to TestLink maybe ... ?)
(0003925)
fman (administrator)
2008-08-06 15:45

I must continue to say that using custom fields for this is IMHO, WRONG in capital letters.
We have user contribution regarding test case automation that uses a couple of CF identifying it's function by name given to CF.
Now we want to add a new class of CF, OK but to extend what we can not has thinked about yet, but not for attributes that IMHO fit the model.

I think that doing a new implemetation using new tables and/or fields will result in:
- better and clear implementation
- less maintainance problems
- we will develop it in less time

Repeat I agree anyway to analisys regarding what new class of CF can be useful, but I would like to implement vladimir request NOT using it.
Later we can this new CF type to extend feature.

I think CF are very useful, must overusing them we will finish with a bad DB schema (CF extends dinamycally the DB SChema)


Read carefully below please:

FOR Vladimir:
First thing, thanks for your detailed explanation.
I would like to ask you to use it in future for our documentation.

After having reading your explanation I think more and more than
using custom fields is not a good idea.
Best solution is add new attributes to std TL Schema.

Script to execute:
new attribute for test case version object => add new column to table tcversions
we have at least two options:

create a new table called tcscripts, with a following structure

ID: int
NAME: varchar : script name to be displayed at user interface level
SOURCE: text: can hold script code NULL, must be NULL if next field (TASK) is specified.
TASK: varchar: name of script to be executed (path name on other server?), must be NULL
        id SOURCE hold script code.

this table is a sort of scripts yellow pages.

Things to understand:
this yellow pages is system wide, or we want to do partitions using test projects.
If we choose to do this partitions then:
TESTPROJECT_ID column must be added.

Do we need some additional info like: server where TAKS exist ?
May be reading documentation from other existent automation frameworks like selenium or STAF
can be useful, to do this design.
What do you think ?


Then in tcversions we can add field: SCRIPT_ID, can be NULL if this test case can not be automated.
If test case can be automated then SCRIPT_ID will point to a record on tcscripts table.

Other choice :
Just add a new column in tcversions table

TASK: varchar: name of script to be executed (path name on other server?), must be NULL
      this field will be used if test case has been declared with execution type AUTOMATED.
      
As you can see, we can add this info permanently to TL structure.


Just for the records: we have already have added some contributed feature regarding test exec automation
that use CF.
One issue obviously if how to Identify function of every CF you want to use.
Alternatives:
- Identify function by CF name
- Identify function by CF type ( I suppose is what you want to do).
       
Issues with "Identify function by CF type" option:
need to add some control at user interface level to AVOID linking of more that one CF of some type.
Example:
using more that one CF of "AUTOMATED SCRIPT NAME" type on a test project must be allowed ?

I would like to highlite again, that I think that a better solution than CF is creating an
specific sctructure for test automation on TL.

Other aattributes that you are explained:
'Start date/time', 'End date/time' and 'Frequency'

IMHO are generic enough for every automation method you can plan to use.

This data can be added to tcversion_tcplan table:

FROM:

CREATE TABLE `testplan_tcversions` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `testplan_id` int(10) unsigned NOT NULL default '0',
  `tcversion_id` int(10) unsigned NOT NULL default '0',
  `node_order` int(10) unsigned NOT NULL default '1',
  `urgency` smallint(5) NOT NULL default '2',
  PRIMARY KEY (`id`),
  UNIQUE KEY `tp_tcversion` (`testplan_id`,`tcversion_id`)
) DEFAULT CHARSET=utf8;


TO
CREATE TABLE `testplan_tcversions` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `testplan_id` int(10) unsigned NOT NULL default '0',
  `tcversion_id` int(10) unsigned NOT NULL default '0',
  `node_order` int(10) unsigned NOT NULL default '1',
  `urgency` smallint(5) NOT NULL default '2',
   start_exec_at datetime NULL, ****>>> (better names can be found)
   end_exec_at datetime NULL,
   frequency int DEFAULT 0 ( a new table with frequencies can be created ? or here
                              we give a delta in seconds and use -1 to express RUN ONCE
                              or other option)
   
   
  PRIMARY KEY (`id`),
  UNIQUE KEY `tp_tcversion` (`testplan_id`,`tcversion_id`)
) DEFAULT CHARSET=utf8;

This field can be filled by user during test case linking as you have suggested.


IMHO, this is a good choice better than CF.

I have no clear ideas to got scripts results, but think your script can create
XML with result data (Kevin Levy has defined format) and launch import of this on TL,
or use current XMLRPC API called from your script to save results.

Anyway we need to discuss this with other Core members of dev team, before taking any official
action.
I have some vague memory of some similar discussion I have had with Martin Havlat, and I need
to search documentation (I do not remember is there is an issue on mantis, regarding this, I need
to search).

I do not want to seem "TO RIGID", what I would like to do is take only a little more time to
discuss this ideas, before start development.
Hope who can wait (may be 15 days or 1 month) before start development.

What do you think ?
I suggest you anyway to give a look to contribution I have mentioned before.


To all reading this:
Please let me know your ideas.
(0003929)
vlada
2008-08-06 19:54

@mhalvat: I agree entirely.

@Francisco: I'd be glad if you would use my example for documentation. (you are free to change it in any way you see fit)

  As much as I like the idea of making automation specific database tables, I'd like to point out that we (my company) need to get this working ASAP.

 Maybe the best thing to do is to both 'enhance existing CF' and to add scripting automation to some degree.

  However we should be aware of potential problems:

 - test scripts need data (we'll need lots of small XML/TXT files in our tests),
 - they often use libraries that may or may not be installed on destination machine
 - we need to be able to run them on arbitrary computer in our LAN (therefore we need some user/password credentials)

 Therefore I don't think it is good to store scripts in database as in general there will be need to have much more than just one file. I think it is enough to have just a string that will specify which command to use to initiate scripts that will be already prepared on test system.

 Solution we plan to use our company is to prepare test environment on some sort of network file system (ntfs or samba), and to use protocol for remote process execution (ssh, rsh, rexec, samba.. ) to start scripts that are already prepared on network file systems. All interpreters, libraries, data files etc will be easy to use by just mounting that fs and starting processes from there. This solution can be used on both windows and linux.

  So the only thing TestLink needs to provide in our case is script name (or command that will be issued to web server where TestLink will be hosted).

  Examples (I'll stick to StarTrek Enterprise TestPlan):

 - this command can be used on linux to log onto remote computer called Bashir.MedicalDepartment to run test that will gather research progress statistics about unknown biological specimens: `ssh bashir.MedicalDepartment -c "umount /mnt/tests; mount testserver:/home/tests /mnt/tests; cd /mnt/tests/medical/;at $datetime1 tc_research_stats.pl > /var/tests/HASH_42839423342.txt; at $datetime2 submit_results_to_testlink.pl /var/tests/HASH_42839423342.txt"`

 - say TestLink is installed by Ferengi merchant Quark and that he wants to automatically check quality of merchandise he is about to purchase. If Ferengi was to run TestLink on MS Windows he would use following command: `SCHTASKS /Create /S \\RomulanTradingOutpost /U Quark /P Money /SC %FREQUENCY% /ST %STARTTIME% /ET %ENDTIME% /TR "NET USE Z: //Tests/QualityControl && Z: && TC_TEST_ROMULAN_BEER.BAT"`

---

 I'd like to point out that Frequency field should not be plain integer which defines time period between runs. It would be much more convenient to use series of ENUMS like EVERY_WORKDAY, DURING_WEEKEND, EVERY_FIRST_MONDAY_IN_MONTH.. and so on.

 I expect 20-30 of these frequency constants. For reference you can check MS Windows Scheduling Utility (Start / Control Panel / Scheduled Tasks / Add Scheduled Tasks / Add scheduled task; or linux cron utility)

---

 Only scripting support I would add to TestLink would be executing given command (field of type string that would be executed via `system()` syscall) and some functions in API that would enable scripts to ask TestLink for CF parameters and send results back.

 Most flexible solution would be to allow scripts to send pure HTML back. This HTML sholud be easily accessable from reports or TestCase execution page. End user should be able to see individual TestCase result page with single click.

 It would be nice if you could provide me with more information on how to implement 'enhanced CF functions'.



 Best regards,
 Vlada
(0003930)
fman (administrator)
2008-08-06 20:07

1. Let me know what is your dead line to have this up and running.
2. I will review with details you new explanation and will try to give again
   a solution using new tables instead of cf ( I will try to 'convert you' ;) ).
3. I will draft a solution using CF ( i do not like it) and give you some indications to develop.

4. queries can not be MySQL specific, must be supported by Postgres and MSSQL

Important:
this development must be done for 1.8 not for 1.7, or must be simple to port from 1.7 to 1.8.
I will have a little more time to develop after 2008-08-15.

I will ask you to send your code frequently to be reviewed whe you will develop this, in order to add it to stable branch.
(0003931)
vlada
2008-08-06 20:44
edited on: 2008-08-06 20:47

1. I'll need to have prototype working (and to be stable) until the end of this month. That means that we need to solve most of design related issues in following few days

2. Thanks, if it proves that adding scripting related tables does not prolong implementation, I'd be happy to work on that.

  Greatest problem I have right now is lack of understanding source code. To solve this I have been developing 'reverse engineering documentation' for few days on classes I consider important for these modifications.

  Classes I have worked out so far are: cfield_mgr.class.php; testcase.class.php and testplan.class.php.

3. Thanks. It would be nice if you colud do all database related design, and instruct me in what way do I need to modify core classes.

4. I'd be glad to post patches on regular basis for your review.

  Best regards,
  Vlada

(0003932)
fman (administrator)
2008-08-06 21:00

- Not a lot of time
- these are the right files.
- I would like to have your documentation.
- Remember that our cf are based on mantis => mantis doc can be useful
- feel free to ask ( i have developed, ported CF from mantis to cf)

regards
(0003933)
vlada
2008-08-06 21:06

@mhavlat:

>>> - feature: send a log for a test execution via API and save as attachment

 I agree with this. Attachments could be used to gather reports sent by testcases. This way TestLink would take care of removing reports after TestPlan removal (or removing specific TC from TestProject etc, etc)

>>> - set CF "precondition test case" to allow check chain dependencies (hmmm, we can implement it directly to TestLink maybe ... ?)

 I don't fully understand this. Can you pls elaborate?
(0003934)
fman (administrator)
2008-08-06 21:19

Pre and post condition can be good thing but can not be managed using CF.
(0003935)
mhavlat (reporter)
2008-08-07 03:59

>>> create a new table called tcscripts, with a following structure
I fully agree. But this is not the current issue. In addition there is not direct dependence. Please create a new report to solve it.

>>>'Start date/time', 'End date/time' and 'Frequency'
>>>IMHO are generic enough for every automation method you can plan to use.
>>>This data can be added to tcversion_tcplan table:
I disagree.
1. The one user only needs just these attributes. Your solution doesn't allow to use different ones. In addition these attributes are not typical for test automation.
2. The tcversion_tcplan table is performance critical structure.
I still believe that CF are appropriate solution.

Timeframe: I would like to release RC1 in month. It's important to catch this term with CF development. RC1 means, that bug fixing is accepted for the release, but no new development. I'm glad that it fits your plan. No problem to work on API later. API is still experimental in my eyes.

>>> "precondition test case"
Francisco is right. See 1663.

Design notes:
Guru for CF is Francisco. Guru for API is Asiel.
I also must do reverse engineering if I need to do some work. So I will improve our docs if you are able to send your exploration (no problem to send fragments without formating). BTW: we are not developers, so some pieces of code are not good ...
(0003943)
fman (administrator)
2008-08-07 19:37
edited on: 2008-08-07 20:01

@vlada Regarding API - you can also talk with me

Here is my desig (done before reading note 3935 by martin)

1. TL API must be extended.
External test execution system that needs information stored on TL MUST AVOID direct access to TL tables.
Instead TL XMLRPC API must be used.

Proposal of new functions:

- getScriptEnvironment(testcase_external_id)
  will return: script name
                server where script will be executed.

- getScriptConfig(testcase_external_id, tesplan_id)
  will return:
                start_exec_time
                end_exec_time
                script time out
                execution frequency


2. Database changes
   All new attributes needed to full fil this feature will be managed creating new attributes for existent TL item/building block (test cases, test plan , etc).

2.1 New attributes for Test Case specification (Script Environment)

During test case design (test case specification) for test cases with "excution type" set to automated, following new attributes will be available:

- script name
- server where script will execute

A new table called TCSCRIPTS ( than can be considered an EXTENSION of TCVERSIONS table) with a following struct will be created:

ID
 TESTCASE_ID OR TCVERSION_ID
 TESTCASE_ID -> if we want SAME script for ALL versions
 TCVERSION_ID -> if we want to have different scripts for different versions

NAME: script name
SERVER: server name or IP
NOTES: user's comments

Access to this table information will be done on LEFT OUTER on TCSCRIPTS

2.2 New attributes for tcversion linked to test plan (Script Configuration)

Test case version must be linke to test plans in order to be executed.
Same test case can be linked to several test plans, and is possible that automated execution in every test plan has different requirements (start time, edn time, etc).

This data (that can be considered and EXTENSION to testplan_tcversions table)
will be present on new table TCSCRIPTSCFG or TCSCRIPTSCHED.
Attributes
START_EXEC_TIME
END_EXEC_TIME
FREQUENCY_CODE:
               example EVERY_MONDAY, ONCE, etc.
               This code will be managed suing a new table CRONTYPES.

IS_ACTIVE: 1/0 - useful for disabling automatic execution without having to loose all config data.

TIMEOUT
ARGUMENTS: this field can contain a custom specific XML string or other format (free format that must be known to execution scripts)
with arguments that must be passed to script to be executed.

2.3 returning URL to scripts results
    IMHO we can use NOTE field present in executions table

---------------------------------------------------------------

@ martin & vladimir:
Please give a look to this.

I will read ASAP prior martin comments in detail

First ISSUE on Martin comments:

This feature can not be released with RC1 if RC1 will be released on 20080901,
becuase IMHO, will not be tested enough.

Regards

Francisco
(I will try to write create table scripts, to post here)

Hope we can choose this kind of solution and not CF based

(0003951)
vlada
2008-08-08 23:25

@francisco:

  Functions that would be useful in our case are:

   - getScriptsScheduledFrom($testplan, $tc_version, $from_datetime)
   - getScriptsScheduledBetweenDates($testplan, $tc_version, $datetame1, $datetime2)

  We are planing to schedule scripts for execution as soon as they are assigned to TestPlan. But it might be more robust to add field 'Scheduled' so that TestLink could know if certain script is actually scheduled or not. (destination server might not accept new job because because it could be down or temporally unavailable). This can also help Scheduling Application determine which applications have been scheduled and which still have to be processed.

  API functions supporting 'scheduled' field:

  - SetScheduled($tc_plan, $tc_version, $value)
  - IsScheduled($tc_plan, $tc_version)
  - GetUnscheduledScripts()

  It would be more efficient if callback function could be registered - (this way 'Scheduling application' could know when new assignments are made), so that it does not have to poll server for scheduled tasks all the time.

  For reporting - it would be nice to have CFs for Scripts. And it would be useful to introduce CF of type 'file'. So that user can upload file (report) to TestLink and make that report available via single click. Backend logic would manage files stored in webservers 'upload' directory.

----

  But most of these features will be available if we make CFs a bit more powerful. I don't know if separate tables are needed.

  Best Regards,
  Vlada
(0003952)
mhavlat (reporter)
2008-08-09 04:15

Guys,
could you consider to remain universal? We should implement API function that generally get/set CF (for a type). In this case users could add own CFs and the purpose of this issue will be satisfied as well. It will bring great value. Logic could be done on scripting side (not TL).

Something like that:
 - getCFxxxxxxxxx($testplan, $tc_version)
 - getTCwithCFxxxxxxxxx($testplan, $CFname, $CFvalue)
 - setCFxxxxxxxxx($testplan, $tc_version, $CFname, $CFvalue)
 - isCFxxxxxxxxx($testplan, $tc_version, $CFname)

The design in above notes fits just your case (is too specific) and do not allow easy extension. I still think that using CF and general API function for CF is better for maintenance and satisfy more users.

Vlada, there is Test Plan attribute, that says if the test plan is active or not. It could be useful to use it to run just valid Test Plans.

Francisco, I was fine with original scope of the implementation for RC1. There was low risk of problems. In addition, I can mark it as experimental feature if it will be appropriate in the time of release.
I will be happy to have agreement of Andreas, if you want to add attributes: START_EXEC_TIME, END_EXEC_TIME and FREQUENCY_CODE in the DB schema. IMHO It's really specific using.
(0004050)
mhavlat (reporter)
2008-09-08 20:19

How much work remains?
(0004075)
fman (administrator)
2008-09-10 17:28

IMHO a lot.
First we need to take all this discussion a generate a final draft.
(0004295)
mhavlat (reporter)
2008-10-07 15:32

I see that we are near RC1 date. It seems that this feature remains out of scope 1.8. Vlada, could you confirm, that the feature is not still ready?
(0005247)
mhavlat (reporter)
2009-02-05 00:25

Vlada, could you briefly note your status? Thanks.
(0007312)
mhavlat (reporter)
2009-06-20 02:17

Looks like Vlada will not interest. It should be reassigned
(0007314)
fman (administrator)
2009-06-20 23:11

@Martin:
as (I hope ) you know we already have parts of these implementations( I've developed CF for test plan design, and couple of functions on API) to manage CF

- Issue History
Date Modified Username Field Change
2008-07-30 22:16 vlada New Issue
2008-08-05 00:40 fman Note Added: 0003885
2008-08-05 00:57 vlada Note Added: 0003888
2008-08-05 13:56 fman Note Added: 0003895
2008-08-05 18:57 vlada Note Added: 0003903
2008-08-05 19:08 fman Note Added: 0003904
2008-08-05 22:12 vlada Note Added: 0003915
2008-08-05 23:40 fman Note Added: 0003919
2008-08-06 04:32 mhavlat Note Added: 0003922
2008-08-06 04:44 mhavlat Note Added: 0003923
2008-08-06 15:45 fman Note Added: 0003925
2008-08-06 19:54 vlada Note Added: 0003929
2008-08-06 20:07 fman Note Added: 0003930
2008-08-06 20:44 vlada Note Added: 0003931
2008-08-06 20:45 vlada Note Edited: 0003931
2008-08-06 20:47 vlada Note Edited: 0003931
2008-08-06 21:00 fman Note Added: 0003932
2008-08-06 21:06 vlada Note Added: 0003933
2008-08-06 21:19 fman Note Added: 0003934
2008-08-07 03:59 mhavlat Note Added: 0003935
2008-08-07 03:59 mhavlat Status new => assigned
2008-08-07 03:59 mhavlat Assigned To => vlada
2008-08-07 19:37 fman Note Added: 0003943
2008-08-07 19:47 fman Note Edited: 0003943
2008-08-07 19:48 fman Note Edited: 0003943
2008-08-07 20:01 fman Note Edited: 0003943
2008-08-08 23:25 vlada Note Added: 0003951
2008-08-09 04:15 mhavlat Note Added: 0003952
2008-08-21 00:36 fman Summary New feature: Custom fields for TestPlan assignment => Using Custom fields for TestPlan assignment for manage test automation data
2008-08-21 00:39 fman Relationship added related to 0001680
2008-09-08 20:19 mhavlat Note Added: 0004050
2008-09-10 17:28 fman Note Added: 0004075
2008-10-07 15:32 mhavlat Note Added: 0004295
2009-02-05 00:25 mhavlat Note Added: 0005247
2009-06-20 02:17 mhavlat Note Added: 0007312
2009-06-20 02:17 mhavlat Assigned To vlada =>
2009-06-20 02:17 mhavlat Status assigned => acknowledged
2009-06-20 02:18 mhavlat Relationship added parent of 0000056
2009-06-20 02:18 mhavlat Relationship replaced related to 0000056
2009-06-20 23:11 fman Note Added: 0007314
2010-02-02 02:00 fman Status acknowledged => assigned
2010-02-02 02:00 fman Assigned To => fman
2010-02-02 02:01 fman Status assigned => resolved
2010-02-02 02:01 fman Fixed in Version => 1.8.5 (bug fixing)
2010-02-02 02:01 fman Resolution open => fixed
2010-05-01 20:33 fman Status resolved => closed
2017-04-27 05:13 fman Relationship added related to 0007857



Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker