Changes between Version 115 and Version 116 of TestManagerForTracPlugin
- Timestamp:
- May 9, 2015, 2:49:13 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TestManagerForTracPlugin
v115 v116 7 7 == Summary 8 8 9 Afull test management life-cycle: definition, planning, execution, statistics.9 This plugin implements a full test management life-cycle: definition, planning, execution, statistics. 10 10 11 11 This test management Trac plugin can be used to create '''[wiki:TestManagerForTracPlugin#TestCases Test Cases]''', organize them in [wiki:TestManagerForTracPlugin#TestCatalogs Catalogs] and generate '''[wiki:TestManagerForTracPlugin#TestPlans Test Plans]''' to track their execution status and outcome. … … 25 25 * Copy/move individual or a set of test cases among catalogs, or organize the catalogs contents easily using drag and drop. 26 26 * '''Defining one or more test plans (test rounds) '''for each test (sub-)catalog, based on all or a portion of the test cases in a (sub-)catalog. Specifying whether the textual contents of the test cases in a plan should be frozen at the current version, or will always be linked to the latest version. 27 * '''One-click changing status of a test case''' - i.e.marking a test case in a particular test plan as successful or failed.27 * '''One-click changing status of a test case''', ie marking a test case in a particular test plan as successful or failed. 28 28 * '''Ticket integration''': opening tickets directly from a (usually failed) test case, keeping track of the relationship. Navigating from a test case to its related tickets and vice-versa. 29 29 * Test cases, catalogs and plans can have their own '''custom properties''', defined in trac.ini like tickets. All property types are supported: text, text area, listbox, radio buttons, checkbox. … … 59 59 * All of the test objects, i.e. catalogs, test cases, test plans and test cases in a plan (i.e. with a status and a status change history), support: 60 60 * '''[#Customfields Custom properties]''', which can be declared in the trac.ini file and will be available to the User for change, stored in the database and available to change listeners. 61 * Property and status change history 62 * Listener interface to be notified of object creation, modification and deletion 63 * '''[TestManagerForTracPluginWorkflow Customizable Workflow]''' state machine, declared in the trac.ini file, with the same syntax as for Ticket workflows (I may have reused some existing code here :-)61 * Property and status change history. 62 * Listener interface to be notified of object creation, modification and deletion. 63 * '''[TestManagerForTracPluginWorkflow Customizable Workflow]''' state machine, declared in the trac.ini file, with the same syntax as for Ticket workflows. 64 64 * '''[TestManagerForTracPluginWorkflow#Howtoprovidecustomoperations Customizable Workflow Operations]''', via a plugin api so that any component can provide its custom operations to be performed upon any workflow action, as defined in the trac.ini file. 65 * Workflow also supports a listener API for components interested in state transitions and actions performed 65 * Workflow also supports a listener API for components interested in state transitions and actions performed. 66 66 * Workflow states also support custom properties, so to be able to convey additional context information on a workflow state and use it in listeners or directly from the database. 67 67 68 * The developed workflow engine is able to work on any Trac Resource, it is not confined to this plugin. You can then define a workflow on any Trac resource, including Wiki pages, declaratively in the trac.ini file. You willthen add a handful of custom code (for example in an ITemplateStreamFilter) to add the markup that the workflow engine generates for you to your desired Trac web page. See [wiki:TestManagerForTracPluginWorkflow#Extendworkflowsupporttoanyofyourartifacts this page] for further details.69 70 Here follows an overview of the plugin functionalities. For a brief [#Tutorialaspowerpointpresentation tutorial], refer to the [http://www.youtube.com/watch?v=BIi3QMT0rT4 Video tutorial on Youtube].68 * The developed workflow engine is able to work on any Trac resource, it is not confined to this plugin. You can then define a workflow on any Trac resource, including Wiki pages, declaratively in the trac.ini file. You then add a handful of custom code (for example in an ITemplateStreamFilter) to add the markup that the workflow engine generates for you to your desired Trac web page. See [wiki:TestManagerForTracPluginWorkflow#Extendworkflowsupporttoanyofyourartifacts this page] for further details. 69 70 For an [#Tutorialaspowerpointpresentation overview] of this plugin's capabilities, see this [http://www.youtube.com/watch?v=BIi3QMT0rT4 video]. 71 71 72 72 == Test Catalogs … … 107 107 * '''Rename page''' button. This function is '''not allowed''' for Test Catalogs, Test Cases or Test Plans. This because the Test Manager plugin uses the page names to keep track of the test artefacts hierarchy information. Submitting a new page name will then throw you a meaningful error. '''To change the Catalog's title''', use the '''Edit this page''' button and change the first text line. It is interpreted as the catalog title. If you '''wish to move '''the object elsewhere, instead, use the 'move' Test Manager functions. 108 108 * '''Delete this version''' button. It will delete the current Test Catalog's '''description Wiki page''', and revert to the last one. This action will have no effect on the changes you may have done to the sub-catalogs or test cases contained within. To undo changes to the Wiki pages of any of these latter objects, go to the corresponding page and work with the Wiki versions accordingly. As long as the Test Catalog internal organization in sub-catalogs and Test Case, Test Manager does not have a "Test Catalog snapshot" kind of functionality, which you may revert to. 109 * '''Delete Test Catalog''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the current Test Catalog, all the contained sub-catalogs, Test Cases, Test Plans and the status history of them. ''' ''Caution''''': there in no undo functionality here.109 * '''Delete Test Catalog''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the current Test Catalog, all the contained sub-catalogs, Test Cases, Test Plans and the status history of them. '''Caution''': there is no undo functionality. 110 110 111 111 || [[Image(TestCatalog01.png_th.png, link=[wiki:TestManagerForTracPluginGallery#TreeviewoftheTestCatalog])]] || [[Image(TestCatalog04.png_th.png, link=[wiki:TestManagerForTracPluginGallery#TabularviewoftheTestCatalog])]] || … … 136 136 They are implemented again as wiki pages, with a naming convention that allows the plugin code to recognize them and treat them appropriately, and with a set of auxiliary database tables. This provides out-of the box support for rich text formatting (using Wiki syntax), attachments and versioning. 137 137 138 To add Test Cases into a Test Catalog, open the catalog, go to the bottom of the page and enter a name for the new Test Case to be created into the appropriate text box (blanks, special characters and case are supported). Then click the button '''Add a Test Case'''. 139 140 You can then add the Test Case description just below the first line (i.e. the title), using WikiFormatting, adding attachments and everything else is supported for Wiki pages.138 To add Test Cases into a Test Catalog, open the catalog, go to the bottom of the page and enter a name for the new Test Case to be created into the appropriate text box (blanks, special characters and case are supported). Then click the button '''Add a Test Case'''. A new wiki page is generated, with a naming convention allowing the plugin code to position it correctly in the catalogs tree, and opened for editing. '''Be careful''' that the first line (the one surrounded by '==') will always be taken as the title of the Test Case, so do not remove this line. You can edit this line to change the test case title, anyway, at any time. 139 140 You can then add the Test Case description just below the first line, ie the title, using WikiFormatting, adding attachments and everything else is supported for Wiki pages. 141 141 142 142 When you are done, save the page '''Submit Changes''' to save your new Test Case. 143 143 144 A Test Case is created in the context of a Test Catalog. Think of it as the '''Test Case''' "class", or "definition". It does not carry i formation about whether the Test Case was executed or when, and wheter it succeded or failed.145 146 To plan a test execution session, you will thengenerate a [#TestPlans Test Plan]. A Test Plan is used to record a specific execution of a set of Test Cases. Thus, a Test Cases also exists in the context of one or more Test Plans. Think of those as Test Case "instances", or "uses". In the context of the Test Manager plugin, these are called '''Test Cases in a Plan'''.144 A Test Case is created in the context of a Test Catalog. Think of it as the '''Test Case''' "class", or "definition". It does not carry information about whether the Test Case was executed or when, and whether it succeeded or failed. 145 146 To plan a test execution session, generate a [#TestPlans Test Plan]. A Test Plan is used to record a specific execution of a set of Test Cases. Thus, a Test Cases also exists in the context of one or more Test Plans. Think of those as Test Case "instances", or "uses". In the context of the Test Manager plugin, these are called '''Test Cases in a Plan'''. 147 147 148 148 A '''Test Case in a Plan, in addition to a basic Test Case''', also records the execution outcomes (or verdicts), ie whether a particular execution of the Test Case in the context of the containing Test Plan was successful or failing. You can also see the complete test status change history at the bottom of the Test Case in Plan page. … … 157 157 * '''Show Related Tickets''' button. Clicking this button will perform a custom query listing all the Tickets related to this Test Case and, if applicable, the containing Test plan. 158 158 * '''Move the Test Case into another catalog''' button. Only available on Test Case definitions. It allows you to cut (into a "virtual" clipboard) the test case, to be eventually pasted into some other (or the same) catalog, or sub-catalog. Push the button, then navigate to the destination catalog and puch the '''Move the copied Test Case here''' button to complete the move operation. Also look at the '''Organize Test Catalogs''' functionality for an alternative way of moving Test Cases. Refer to [#TestCatalogs Test Catalogs] for details. 159 * '''Duplicate the Test Case''' button. Only available on Test Case definitions. Lets you make an exact copy of this Test Case definition. Note that the test execution statuses (i.e. successful, failed, etc.)associated to the original Test Cases in any Test Plan are not duplicated along with the Test Case definition.159 * '''Duplicate the Test Case''' button. Only available on Test Case definitions. Lets you make an exact copy of this Test Case definition. Note that the test execution statuses, ie successful, failed, etc, associated to the original Test Cases in any Test Plan are not duplicated along with the Test Case definition. 160 160 * '''Add to a Test Plan''' button. Only available on Test Case definitions. Allows you to add the Test Case to one or more suitable Test Plans, i.e. Test Plans that have been defined as not containing all the test cases (current and future) of the associated Test Catalog, but only a selected set of them. 161 161 * '''Object Change History''' section. In addition to the standard Wiki versioning, test objects support their own change history, which lets you inspect who changes which property and when, also showing its old and new value. This is also particularly useful for [#Customfields Custom Fields] you may add to the test objects. See [#TestArtifactChangeHistory Test Artefact Change History] for more details. … … 164 164 * '''Rename page''' button. This function is '''not allowed''' for Test Catalogs, Test Cases or Test Plans. This because the Test Manager plugin uses the page names to keep track of the test artefacts hierarchy information. Submitting a new page name will then throw you a meaningful error. '''To change the Test Case's title''', use the '''Edit this page''' button and change the first text line. It is interpreted as the test case title. If you '''wish to move '''the object elsewhere, instead, use the 'move' Test Manager functions. 165 165 * '''Delete this version''' button. It will delete the current Test Case's '''description Wiki page''', and revert to the last one. 166 * '''Delete page''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the current Test Case definition and all of the Test Case instances in any Test Plan, including their status change history. ''' ''Caution''''': there in no undo functionality here.166 * '''Delete page''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the current Test Case definition and all of the Test Case instances in any Test Plan, including their status change history. '''Caution''': there is no undo functionality. 167 167 168 168 || [[Image(TestCase01.png_th.png, link=[wiki:TestManagerForTracPluginGallery#SampleTestCase])]] || [[Image(TestCase02.png_th.png, link=[wiki:TestManagerForTracPluginGallery#LateaddingaTestCasetooneormoreTestPlans])]] || … … 173 173 '''Since: 1.1.0''' 174 174 175 A '''Test Plan''' represents a plan for a particular execution of all the Test Cases in a Test Catalog (or sub-catalog).175 A '''Test Plan''' represents a plan for a particular execution of all the Test Cases in a Test Catalog or sub-catalog. 176 176 177 177 Think for example at the build verification test following a nightly build, or, for traditional projects, Functional Test and eventually Customer Verification Test. … … 216 216 * '''Rename page''' button. This function is '''not allowed''' for Test Catalogs, Test Cases or Test Plans. This because the Test Manager plugin uses the page names to keep track of the test artefacts hierarchy information. Submitting a new page name will then throw you a meaningful error. 217 217 * '''Delete this version''' button. It will delete the associated Test Catalog's description Wiki page, and revert to the last one. 218 * '''Delete page''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the associated Test Catalog. Refer to [#TestCatalogs Test Catalogs] for details about what will be actually deleted. ''' ''Caution''''': there in no undo functionality here.218 * '''Delete page''' button. Pushing this button will ask you for confirmation and, if confirmed, will delete the associated Test Catalog. Refer to [#TestCatalogs Test Catalogs] for details about what will be actually deleted. '''Caution''': there is no undo functionality. 219 219 220 220 You have two ways of setting the execution outcome of a Test Case in a particular Test Plan (see figures below): 221 221 222 1. Directly from the test plan tree or tabular view, by clicking on the traffic-light icon and choosing the new color from the menu that opens. (Since 1.4.7)222 1. Directly from the test plan tree or tabular view, by clicking on the traffic-light icon and choosing the new color from the menu that opens. Since 1.4.7. 223 223 1. By opening the test case first, by clicking on its name in the Test Plan tree or table, and then clicking on the corresponding traffic-light at the bottom of the page. 224 224 … … 230 230 == Moving or Copying Test Cases from one catalog to another 231 231 232 It is also possible to move a single Test Case, or copy multiple Test Cases into a different catalog, with an experience similar to cut&paste.232 It is also possible to move one or more Test Cases into a different catalog, with an experience similar to cut&paste. 233 233 234 234 As an alternative, it is also possible to ![OrganizingthecontentsofaTestCatalog graphically organize the contents of a Test Catalog] using drag&drop. … … 236 236 === Moving a single Test Case 237 237 238 To move a single Test Case from one catalog into another , you:238 To move a single Test Case from one catalog into another: 239 239 240 240 1. Open the Test Case … … 247 247 === Copying multiple Test Cases 248 248 249 To copy one or more Test Cases, even from different catalogs, and paste them all together into a destination (sub-)catalog , you:249 To copy one or more Test Cases, even from different catalogs, and paste them all together into a destination (sub-)catalog: 250 250 251 251 1. Open the Catalog. Expand the tree nodes as you like. … … 264 264 Use '''drag and drop''' to move test cases into different catalogs or changing their order. As long as the '''Sort a test plan's test cases''' option in the Test Manager's '''Settings''' panel is set to '''User Specified''', the test cases will be displayed in the specified order when browsing the catalog and any associated test plans. 265 265 266 '' Currently, you can only move Test Cases but not Test Catalogs. In addition to that, copying is not supported yet.''266 '''Note:''' Currently, you can only move Test Cases but not Test Catalogs. In addition to that, copying is not supported yet. 267 267 268 268 Click '''Save''' to submit your changes. … … 280 280 The association is particularly useful when browsing the [#TestManagementandExecutionStatistics Test Management and Execution Statistics]. 281 281 282 You can specify a set of properties to control the contants of the new ticket's summary. In the {{{[testmanager]}}} section of the trac.inifile:282 You can specify a set of properties to control the contants of the new ticket's summary. In the {{{[testmanager]}}} section of the `trac.ini` file: 283 283 284 284 ticket_summary_option: How to generate the ticket summary. Available options are: … … 308 308 Two sample configurations follow: 309 309 310 {{{ 311 #!ini 310 {{{#!ini 312 311 [testmanager] 313 312 ticket_summary_option = fixed_text … … 315 314 }}} 316 315 317 {{{ 318 #!ini 316 {{{#!ini 319 317 [testmanager] 320 318 ticket_summary_option = last_n_catalogs … … 329 327 * planname: The name of the Test Plan 330 328 331 For example, to get the test case number, you template will have something like:329 For example, to get the test case number, your template will have something like: 332 330 333 331 {{{ … … 339 337 === Showing Tickets related to a Test Case 340 338 341 While browsing a Test Case, either inside or outside of a Test Plan, you can list all of its related Tickets - i.e.the Tickets that were opened using the above '''Open a Ticket on this Test Case''' button.339 While browsing a Test Case, either inside or outside of a Test Plan, you can list all of its related Tickets, ie the Tickets that were opened using the above '''Open a Ticket on this Test Case''' button. 342 340 343 341 To do this, just browse the Test Case and '''click on the Show Related Tickets button'''. 344 342 345 If you are browsing a Test Case "definition", i .e.from a Test Catalog, you will be shown all of the Tickets opened against the Test Case '''in any Test Plan'''.343 If you are browsing a Test Case "definition", ie from a Test Catalog, you will be shown all of the Tickets opened against the Test Case '''in any Test Plan'''. 346 344 347 345 If you are instead browsing a Test Case in a specific Test Plan, you will be shown all of the Tickets opened against the Test Case '''in that specific Test Plan'''. … … 439 437 You can export to CSV format a Test Catalog or a Test Plan. 440 438 441 In the Test Catalog and Test Plan pages you will find an "Export 439 In the Test Catalog and Test Plan pages you will find an "Export..." button. 442 440 443 441 The export format is designed for you to elaborate your external statistics, but also to eventually import the stuff back into another Test Manager plugin evironment, as soon as a compatible import feature will be implemented :D (the current import feature is simpler than that). … … 481 479 Custom fields can be added to the four test objects and to the [wiki:TestManagerForTracPluginWorkflow workflow] state object, by declaring them in the trac.ini file. 482 480 483 The syntax is the same used for custom Ticket properties, only the name of the inifile sections are specific: you must use the test artefact type name followed by "-tm_custom".481 The syntax is the same used for custom Ticket properties, only the name of the `trac.ini` file sections are specific: you must use the test artefact type name followed by "-tm_custom". 484 482 485 483 The test artefacts type names are the following: … … 490 488 * testcaseinplan 491 489 492 For example, the following sections in the trac.ini file define custom properties for each of the above artefacts. 493 494 {{{ 495 #!ini 490 For example, the following sections in the `trac.ini` file define custom properties for each of the above artefacts. 491 492 {{{#!ini 496 493 [testcatalog-tm_custom] 497 494 remarks = text … … 527 524 Once defined in the trac.ini file as above, custom fields will be available to the User for browse and for editing in the Web page, as shown next. 528 525 529 '''Note : Editing custom properties requires the TEST_MODIFY permission.'''526 '''Note''': Editing custom properties requires the TEST_MODIFY permission. 530 527 531 528 The following screenshot shows a custom "platform" field added to the Test Case artefact, and how it is presented to the User for editing. … … 545 542 The default outcomes are configured in trac.ini at plugin installation (or upgrade) time as follows: 546 543 547 {{{ 548 #!ini 544 {{{#!ini 549 545 [test-outcomes] 550 546 green.successful = Successful … … 553 549 default = to_be_tested 554 550 }}} 551 555 552 You can '''customize the outcomes''' at any moment by adding new outcomes, or modify the descriptions of the current ones. Do not delete previous outcomes if you have already assigned them to any of your test cases. 556 553 557 554 For example, to add a new outcome named "It's a Mess!!!" to the failures, add a line like the following, in trac.ini: 558 555 559 {{{ 556 {{{#!ini 560 557 red.bigmess = It's a Mess!!! 561 558 }}} … … 575 572 Every object which has a workflow defined is created in a "new" state, so every transition should consider this as the first state in the state machine. 576 573 577 This is a sample content of the trac.ini file to associate a workflow to the Test Case object. [[BR]] 578 579 {{{ 580 #!ini 574 This is a sample content of the trac.ini file to associate a workflow to the Test Case object: 575 576 {{{#!ini 581 577 [testcase-resource_workflow] 582 578 review = new,changes_requested -> under_review … … 604 600 Your quality process may require your test catalogs and test cases to follow particular templates. With the Test Manager, you can define templates for your test catalogs and your test cases. When you create a new test catalog or test case, their description will be filled with the templates you have defined. 605 601 606 To create templates, open the '''Administration''' tab and go to the '''Test Manager -> Templates '''section.602 To create templates, open the '''Administration''' tab and go to the '''Test Manager -> Templates''' section. 607 603 608 604 [[Image(Templates01.png_th.png, link=[wiki:TestManagerForTracPluginGallery#TheTemplatesmanagementsectionintheTestManagerAdministrationpanel])]] … … 671 667 * Number of days between each data point: determines the scale, or granularity, of the charts, in terms of days per single piece of data. 672 668 673 In alternative to using the administration panel, you can directly edit the trac.ini file: 674 675 {{{ 676 #!ini 669 In alternative to using the administration panel, you can directly edit the `trac.ini` file: 670 671 {{{#!ini 677 672 [testmanager] 678 673 default_days_back = <number of days back from today> … … 682 677 For example: 683 678 684 {{{ 685 #!ini 679 {{{#!ini 686 680 [testmanager] 687 681 default_days_back = 14 … … 733 727 == Tutorial 734 728 735 '''TODO:''' These tutorials document release 1.0.3 and so need to be updated with the Test Plan and other recent features. Refer to the '''[http://www.youtube.com/watch?v=BIi3QMT0rT4 Video tutorial on Youtube]''' for more up-to-date information.729 '''TODO:''' These tutorials document release 1.0.3 and so need to be updated with the Test Plan and other recent features. Refer to the '''[http://www.youtube.com/watch?v=BIi3QMT0rT4 video tutorial on Youtube]''' for more up-to-date information. 736 730 737 731 * attachment:"UserGuide_part_1.ppt" … … 773 767 '''Trac 0.12 and 1.x are supported''', and also '''Python 2.6 and 2.7'''. 774 768 775 '''Note:''' If you are using '''MySQL''' or '''PosgreSQL''', the database user must have read access to the trac.inifile.769 '''Note:''' If you are using '''MySQL''' or '''PosgreSQL''', the database user must have read access to the `trac.ini` file. 776 770 777 771 The plugin can be installed as usual, from the Trac administration panel, and requires a database upgrade. … … 805 799 806 800 Try this from the command line: 807 808 {{{ 801 {{{#!sh 809 802 python -c "import pkg_resources" 810 803 }}} 811 If you get no output, setuptools is installed. Otherwise, you'll need to install it before plugins will work in Trac. 804 805 If you get no output, then setuptools is installed. Otherwise, you'll need to install it before plugins will work in Trac. 812 806 813 807 '''Did you get the correct version of the Python egg?''' 814 808 815 Python eggs have the Python version encoded in their filename. For example, `TestManager-1.0.0-py2.7.egg` is an egg for Python 2.7, and will not be loaded if you're running a different Python version (such as 2.5 or 2.6).809 Python eggs have the Python version encoded in their filename. For example, `TestManager-1.0.0-py2.7.egg` is an egg for Python 2.7, and will not be loaded if you're running a different Python version, such as 2.5 or 2.6. 816 810 817 811 Also, verify that the egg file you downloaded is indeed a ZIP archive and not the HTML preview page instead. … … 822 816 823 817 * you actually added the necessary lines to the [components] section: 824 {{{ 825 #!ini 818 {{{#!ini 826 819 [components] 827 820 tracgenericclass.* = enabled … … 830 823 }}} 831 824 * the package/module names are correct 832 * the value is "enabled", not e.g."enable"825 * the value is "enabled", not "enable" 833 826 834 827 '''Check the permissions on the egg file and on the trac.ini file''' … … 836 829 The user user to run Trac (either tracd or Apache) must be able to read the egg files. 837 830 838 Also, it's been reported that for PosgreSQL also its user must be able to read trac.ini.831 It has been reported that for PosgreSQL also its user must be able to read the `trac.ini` file. 839 832 840 833 '''Check the log files''' … … 854 847 Only one version of the plugin can be loaded for each running Trac server (ie each Python process). The Python namespaces and module list will be shared, and it cannot handle duplicates. Whether a plugin is enabled or disabled makes no difference. 855 848 856 A globally installed plugin (typically setup.py install)will override any version in global or project plugins directories. A plugin from the global plugins directory will be located before any project plugins directory.849 A globally installed plugin, typically setup.py install, will override any version in global or project plugins directories. A plugin from the global plugins directory will be located before any project plugins directory. 857 850 858 851 '''If your Trac server hosts more than one project''' (as with TRAC_ENV_PARENT_DIR setups), then having two versions of a plugin in two different projects will give uncertain results. Only one of them will load, and the one loaded will be shared by both projects. Trac will load the first found - basically from the project that receives the first request. 859 852 860 Having more than one version listed inside Python site-packages is fine (ie. installed with setup.py install) - setuptools will make sure you get the version installed most recently. However, '''don't store more than one version inside a global or project plugins directory''' - neither version number nor installed date will matter at all. There is no way to determine which one will be located first when Trac searches the directory for plugins.853 Having more than one version listed inside Python site-packages is fine, ie installed with `setup.py` install, as setuptools will make sure you get the version installed most recently. However, '''don't store more than one version inside a global or project plugins directory''': neither version number nor installed date will matter. There is no way to determine which one will be located first when Trac searches the directory for plugins. 861 854 862 855 '''Have you restarted Apache?''' … … 866 859 '''If all of the above failed''' 867 860 868 OK, so the logs don't mention these plugins, the egg is readable, the python version is correct and the egg has been installed globally (and is enabled in the trac.ini ), you restarted Apache and it still doesn't work or give any error messages or any other indication as to why?861 OK, so the logs don't mention these plugins, the egg is readable, the python version is correct and the egg has been installed globally (and is enabled in the trac.ini file), you restarted Apache and it still doesn't work or give any error messages or any other indication as to why? 869 862 870 863 Open a ticket here. The plugins maintainers watch ticket notifications continuously. … … 879 872 880 873 '''Author:''' [wiki:seccanj] [[BR]] 881 '''Maintainer:''' [ wiki:seccanj] [[BR]]874 '''Maintainer:''' [[Maintainer]] [[BR]] 882 875 '''Contributors:'''