Macrotone

The menu items displayed from this menu item display all of the known issues identified with Macrotone Consulting Ltd. released products.

It also includes any outstanding issues associated with previous releases that have not been resolved in the latest current release of the products.

For convenience the products have been separated out so that each product has its own separate section.

If you know of any item that is not included in the lists please let us know so that we may accurately record and thus hopefully resolve the item.

Issues may be reported on the appropriate forum or via the Issue Tracker 'Raise an Issue' form.

Thank you

Macrotone Consulting Ltd.

 

Issue Tracker Known Issues

IP Mapping Known Issues

JAudit Known Issues

Password Control System and User Plugin Known Issues

Rialto Known Issues

 

This support Issue Tracker FAQ (Frequently Asked Questions) is intended to assist you in answering some of the more common questions that are raised. It is intended to supplement the Issue Tracker documentation.

Issue Tracker is a Joomla 2.5/3.x component that assists in the tracking of issues or problems with a project, or an item that can be uniquely identified. Based upon a product originally running upon an Oracle database using Oracle's Application Express product it has been used internally for several years. This version has now been ported over to Joomla and following extensive internal testing is now being made available to the wider public. The product documentation describes the product in more detail.

If you find the product useful please consider making a donation to fund future development and support.

 

Yes. Release 1.4.1 added support for Joomla 3.1 soon after it was released. Release 1.6 and above runs upon Joomla 2.5.x and Joomla 3.x

 

The latest version of the product documentation is available in PDF format at this web link.

 

No the status code are configurable on the 'Statuses' tab in the Back end administration. There are a few supplied status codes to get one started (which are also used by the sample data), but these can also be edited to anything you desire.

 

The default project and a default user (known as the anonymous user), both with a default identifier of 1, are used to establish defaults for issues where they are not specifically defined. The names and details of these may be changed as the site requires. It is possible to define alternative defaults in the parameters.

It is also possible to define different default assignees for each project or sub-project.

 

No, these are values supplied to help one get started. They are also used by the sample data. They can be edited and changed as required by the site.

Note: Be aware that prior to release 1.2.1 the issue states of Open (id=4) and Closed (id=1) were treated as being special within the component and were used to initiate emails (if configured) to interested parties. In these early releases the specific id's should not be deleted, although the name (spelling) can be changed. In release 1.2.1 these are now configuration options.

 

When installed, the component synchronises the existing Joomla users and creates entries in the it_people table. In addition as new users are registered with Joomla these users are also added to the it_issues table. It is an administrative requirement to set the appropriate setting for these users within Issue Tracker. However it is recognised that occasionally users may be accidentally deleted and for this reason we provide a mechanism to re-synchronise the Joomla and Issue Tracker users table. It is very likely that it will never have to be used on your site. Note that if unregistered users are configured to be created upon the site, that these once deleted will not be recovered by resynchronising since they exist only in the component tables, not in the Joomla users table.

 

Yes the default roles can be defined in the Back end administration. The supplied roles are samples only and are supplied to help get the site started. They may be removed, changed and added too, as the site requires. Note that the 'CEO' and 'Manager' roles are 'special in that they do not accept a default project assigned. This 'feature' is implemented by code and can not (currently) be altered. The sample roles are also used by the supplied sample data.

[It is not a requirement to use any of the roles supplied, but in particular it is probably wise not to use the specific ids associated with the CEO and Manager roles if it is a specific problem for your site.]

 

These instructions are modified from an original article in Joomla magazine September 2011 and reproduced here for your usage.

1. Copy the file ''component.php'' from the folder joomla-installation/templates/system to the root of the the template folder of your template that you are using: (for example: joomla-installation/templates/rhuk_milkyway/component.php).

2. If you need to overwrite some component.php in your new placed template folder, don't do it, as it may include code that the template needs to use (I don't know, but it's safer if you don't do this action in this case).

3. Now open the component.php file in your template folder (you can use wordpad)

4. Search for the line that states: <body class="contentpane"> Around lines 47 on beez_20 template.

5. Now, copy and place this code right under it: <img src="/www.yourwebsite.nl/templates/your-template-folder/your-images-map/logo.png" alt="Logo" /> To use a relative URL use it relative to the httd directory. i.e. src=”<?php echo $this->baseurl ?>/templates/your-template-folder/your-image-map/logo.png” where you use the appropriate folder and logo name for your site.

6. Just change the source of the image so it matches exactly the image that you want included, and that's it!

 

An indefinite level of sub-projects can be created. Just be aware that in the displays that the project name is composed of the concatenation of all the sub project levels along with the top parent project name. If long names are used this could make the complete project name very long.

 

Yes, there is a limited ability to edit the Issue Tracker users, but these users are derived from the Joomla site registered users, so most of the information is derived from Joomla. It really only makes sense to edit the user role, the email notification and default assigned project details.

 

No, only issues and projects marked as 'Published' will be displayable on the front end. Remember also that the display of the projects and issues list is controlled through the menu options as well. It is worth mentioning that the 'Issues List' display can be configured such that only certain projects are included.

Issues marked 'PRIVATE' will not be visible on the front end except to Issue staff and the person who raised the issue.

Note that if suitable configured, issue administrators can edit any issue, published or unpublished in the front end.

 

Yes there are configuration options available on the menu item that determine which columns are visible on the front end. For example it may not be desirable to display the audit fields.

It is also possible with release 1.3.0 (and above) to use custom CSS to style the front end displays.

 

This is part of the design criteria. Users who have a role of CEO or Manager are expected to be associated with many projects by default, so it does not make any sense to assign them any one specific project. The default project is really intended to make the entry of issues easier by populating the project field automatically.

 

There are currently three plug-ins installed with the component.

• The first is a system plug-in that synchronised new Joomla users (and deleted users) with the Issue Tracker users table.
• The second adds the ability to Search the issues, specifically the issues description and title with the standard Joomla search tool.
• The third advanced smart search plug-in is fully functional in release 1.3.2 and above.

 

This initial release does not support any database other than MySQL. This is mainly due to the fact that it has not been tested, more than anything else. There is some work under way to support SQL*Server and MS-Azure but we are generally not aware of any demand.

 

The Issue Tracker component does not use cookies.

 

This is likely to be a problem with the SEF configuration. We have seen this problem on sites where sh404SEF is installed. There is a sh404SEF routine enclosed with the component which resolves most (all?) of the likely problems.

 

The base language supplied is English. However the component has been written specifically to be able to support other languages. There are a number of submitted translations available. The list of available translations is show in the Translations area of the site.

We welcome any submitted language translations that users might like to contribute. These would then be made available to the whole community. We mainly use Transifex for managing component translations.

There is also a article upon our web site with details upon Transifex and how one can contribute as well as instructions upon how to package up a language translation for the a component.

 

The sample data is provided to make it easier for administrators to test out the component. The sample is installed or un-installed from the administrator control panel via two icons. The data is loaded into low identifiers in the tables. Specifically of note is that user identifiers in the range of 2 to 18 are used. These are deliberately kept low to avoid conflict with any Joomla user identifiers, which were prior to Joomla 2.5.4 traditionally in the range above 42. Note that some Joomla components may make use of identifiers in this range and it is advisable to check before installing the sample data to avoid any conflict.

The users in the sample data are not intended to be 'full' Joomla users and are only intended to be examples. These users do not have web site logon credentials. Note that the sample role, priority and status data is installed along with the component and is not removed unless specifically removed by the administrator, or upon un-installing the component.

Release 1.2.0 changed the sample data slightly, as all of the sample users are classed as 'unregistered' users, which means that they are illegible to be assignees for issue resolution.

Be aware that the 'sample data' relies upon the use of database procedures, which may not be available with all Joomla hosting providers. Where the database privilege to create database procedures is not granted, sample data will be unavailable.

 

Joomla 2.5.4 (and above) changed the creation of the site administrator such that the assigned identifier (id) is no longer fixed and is random. This means that there is an increased chance that the id is going to clash with one of the identifiers used by the sample data. A work around has been developed for this problem and is included in release 1.2.0. The future of the sample data being provided is being reviewed and may be removed from future releases.

 

The Issue Tracker component implements the Joomla ACL permissions so it is possible to control what can and cannot be done by changing the permissions for the various groups within the component.

It is common to desire that Registered users can create issues and to achieve this is it is necessary to grant the appropriate permissions to the registered users group.

In the administrator site of the site navigate to the component and choose the 'Options' icon on the top Right Hand Side (RHS).

Pick the 'Permissions' tab.

Click on the Registered field on the LHS (left hand side) of the window:

Under Actions Change the 'Create' setting to 'Allowed' if it is the 'Calculated setting' is 'not allowed'.

If it is desired that Registered user can 'Edit' their own issues, change the 'Edit Own' setting to be 'Allowed' if the Calculated setting is 'Not Allowed'.

It is also possible to control whether to permit 'Public' users to create issues, click on the 'Users' field on the left hand side of the screen and under actions change the 'Create' to allowed. It will be set to 'Not allowed' by default.

Warning: Setting public users to be able to create issues is dangerous, since you have little control over the issues raised. Whilst permissible on a 'closed' site (or a company intranet) this is not a generally recommended setting. This is why Forums, and Bulletin Boards do not allow public users to create forum entries or announcements. We can think of no situation where 'public' users can edit their own issues since there is no way in which public users can be individually identified, and hence any public user could edit any other public users issues. Not something that is desirable at all.

 

Release 1.2.0 introduces the ability for a registered user to be able to edit their issues in the front end. However there are several settings that need to be applied.

1. The 'registered' group need to have the permission 'Edit Own' assigned in the component, accessed via the component options.
2. Each issue needs to have the appropriate ACL permissions applied. Because this feature has been added to the component any existing issues needs to have the ACL settings applied. To do this it is necessary for a back end user to edit the relevant issue and save it. No other change is required and the act of saving the issue will update the assets table appropriately.
3. Front end editing has to be enabled in the component.

Once updated the issue will be editable in the front end by issue administrators or by registered users, who are identified as 'owning' an issue if they are in the issue 'identified by' field.

 

Release 1.2 introduced the additional staff field so that people known to the component can be easily separated into 'staff' and 'non-staff'. Staff member are defined as people to whom issues can be assigned. Formally all people were displayed in the drop down lists which on most sites would create a long drop down list. Now only relevant people who can be assigned issues are shown. If you do not have any staff member assigned then a database error is generated. The installer should have added the flag to all people identified as being assigned to any existing issues on the site, but in the event that this did not happen, the problem can be resolved by assigning people to be 'staff'.

 

The documentation best describes how to change the settings to enable registered (and issue administrators) to edit their issues. If you haven't found the documentation try this link. It might also assist in understanding some of the following.

However to summarise you need to do the following:

• Ensure that the ACL settings for registered users is set to 'Edit Own'.
• If the issues are 'old' (pre release 1.2) issues then you need to edit then in the back end and save them (no need to actually make a change) so that a Joomla 'asset' record is created. All new issues are automatically created with the appropriate asset record.
• To enable users to see their issues, create a 'list issues' menu link and in the menu parameters choose the option 'Show Own Issues', and you probably want to enable 'Child Links' as well. Also ensure that the 'show icons' is set, for the child links.

Now when a user logs in they will see your list issues menu item. If they click on the menu they should a list of all of their raised issues. [Note that the issue must have the user as the person who 'identified' the issue.] Clicking on the child link (to the issue itself) they will be presented with a view of the issue details. In the top right hand corner of the issue there will be some icons. These will be (depending upon menu options chosen), a print icon, an email icon AND if the user is set up correctly an 'edit' icon. [This is the same icon as shown when you edit an article.] If they click on the edit icon they are presented with an edit screen.

 Note: Registered users can 'add additional details' and change only a small set of the issue settings. [There are some component parameters to enable the provision of a full editor, otherwise it will be a simple textarea for data entry.]

 If the person is an 'issue administrator' they have the ability to edit any issue. They also have a different screen display for editing with the ability to change virtually everything about the issue.

 

We have also experienced this type of problem, and have taken some time to discover the reason.  It is not a problem with Issue Tracker specifically, but will impact any front end editor in any Joomla component that allows front end editing.

It is a configuration of the editor that is preventing the display form showing.  As an example we will assume the use of the JCE editor, which is available on most sites.  In the JCE configuration one must modify the specific profile in use on the from end and add the 'Registered' group to the acceptable groups. On the sites we have investigated the default seems to be that the registered group is not able to use the JCE editor in either the 'Default' profile or if enabled the 'Front End' Profile.

 

Release 1.2.0 introduces the ability for registered users and issue administrators to attach images to their raised issues via the supplied editor used on the site. This feature is limited to make use of the Joomla media manager and is intended as a short gap measure until the planned attachment feature is implemented. Release 1.3.0 added this functionality (with some restrictions).

Note that the JCK editor provides some management of image placement on a site to assist in 'image control'.

Release 1.3.0 introduces the ability to add files to an issue. The back end administrator can add an unlimited number of files to an issue.  The front end user can add a single file to an issue if the option is configured. These files are not shown within the issue descriptive files but are stored as associated items.

 

Release 1.2 allow front end editing of issues under certain conditions:

1. An issue administrator is provided with a full editing environment with the ability to change any of the issue fields. A WYSIWYG (What You See Is What You Get) editor is usable.

2. A person who is identified as 'raising' the issue has the ability to provide additional information to an existing issue if they are logged in. They have a limited ability to change the issue details. They are provided with a WYSIWYG editor to provide this 'additional information'. In addition if the logged in user raises a new issue they also have the provision of a WYSIWYG editor.

 

After a failed installation, it may be desired to clean up the Joomla installation.

The following steps can be performed:

Uninstall incomplete IssueTracker extensions in admin/extensions/management tab:

• Issue Tracker - Component
• Issue Tracker - Smart Search
• Issue Tracker - Search
• Issue Tracker - System
• Issue Tracker - Latest Issues Module

In the database, remove last IssueTracker entries in #__menu table (if any).

 

This should never need to be done, but sometimes it happens, that the Joomla! system does not remove all the component data from system while un-installing component, or an installation goes awry due to file system permission problems.

In such a situation, you can do it manually in your database. e.g. in phpMyAdmin.

Before doing this, be sure you understand basic features of SQL and you know what you are doing.

-- This is for Experts only --

Run these queries in your phpMyAdmin

• -- Manual removal of Macrotone Issue Tracker component from Joomla! database
• -- Change the #__ to your Joomla! prefix, e.g. #__extensions to jos_extensions
• DELETE FROM `#__extensions` WHERE `name` = 'com_issuetracker';
• DELETE FROM `#__assets` WHERE `name` = 'com_issuetracker';
• DELETE FROM `#__menu` WHERE `type` = 'component' AND `title` LIKE '%com_issuetracker%';
• DELETE FROM `#__session` WHERE `data` LIKE '%com_issuetacker%';
• DELETE FROM `#__modules` WHERE `module` LIKE '%mod_latest_issues%';
• -- Also need to drop all the Issue Tracker tables and procedures

• DROP TABLE IF EXISTS `#__it_attachment`;
• DROP TABLE IF EXISTS `#__it_issues_log`;
• DROP TABLE IF EXISTS `#__it_progress`;
• DROP TABLE IF EXISTS `#__it_custom_field`;
• DROP TABLE IF EXISTS `#__it_custom_field_group`;
• DROP TABLE IF EXISTS `#__it_issues`;
• DROP TABLE IF EXISTS `#__it_people`;
• DROP TABLE IF EXISTS `#__it_projects`;
• DROP TABLE IF EXISTS `#__it_status`;
• DROP TABLE IF EXISTS `#__it_roles`;
• DROP TABLE IF EXISTS `#__it_priority`;
• DROP TABLE IF EXISTS `#__it_emails`;
• DROP TABLE IF EXISTS `#__it_types`;
• DROP TABLE IF EXISTS `#__it_meta`;
• DROP TABLE IF EXISTS `#__it_chistory`;
• DROP TABLE IF EXISTS `#__it_triggers`;
• DROP PROCEDURE IF EXISTS `#__add_it_sample_data`;
• DROP PROCEDURE IF EXISTS `#__create_sample_issues`;
• DROP PROCEDURE IF EXISTS `#__create_sample_people`;
• DROP PROCEDURE IF EXISTS `#__create_sample_projects`;
• DROP PROCEDURE IF EXISTS `#__remove_it_sample_data`;

 There are also the files within the file system to remove. These are located in the following directories:

• administrator/components/com_issuetracker
• administrator/language/en-GB/com_issuetracker.ini
• administrator/language/en-GB/com_issuetracker.sys.ini
• administrator/language/en-GB/plg_finder_issuetracker.ini
• administrator/language/en-GB/plg_finder_issuetracker.sys.ini
• components/com_issuetracker extensions/update_com_issuetracker.xml
• language/en-GB/en-GB.com_issuetracker.ini
• language/en-GB/en-GB.mod_latest_issues.ini
• language/en-GB/en-GB.mod_latest_issues.sys.ini
• media/com_issuetracker
• plugins/[search|finder|system]issuetracker
• modules/mod_latest_issues

 

It sometimes happens, that component menu links are not displayed in Joomla! administration.

In such a situation, you can do it manually in your database. e.g. in phpMyAdmin.

Before doing this, be sure you understand basic features of SQL and you know what you are doing.

-- This is for Experts only --

Run these queries in your phpMyAdmin

• -- Manual publishing of Macrotone Issue Tracker component menu items in Joomla! administration
• -- Change the #__ to your Joomla! prefix, e.g. #__extensions to jos_extensions
• UPDATE `xxxxx_menu` SET `published` = '1' WHERE `type` = 'component' AND `title` LIKE '%com_issuetracker%';
• UPDATE `xxxxx_menu` SET `component_id` = (SELECT `extension_id` FROM `xxxxx_extensions` WHERE `type` = 'component' AND `name` = 'com_issuetracker') WHERE `type` = 'component' AND `title` LIKE '%com_issuetracker%';

 

The first thing to do is ensure that your system is sending email from Joomla. Typically a user when they register will be sent an email. If this is not working then this problem needs to be resolved first.

Issue Tracker makes use of the Joomla system email configuration so if that is not working is is not an Issue Tracker problem as such.

If that is working then we need to look at the component configuration.  One useful thing to do is to turn on the component debugging because that will create entries in the component log which may/will assist in finding the cause of the problem.

In the Issue Tracker component options there is an Email tab. Within that there is a setting that controls the sending of any email at all. This needs to be set to Yes.

There are then separate settings for each of the individual email messages types that are possible. i.e. Whether a user receives email on issue creation, issue update and for issue closure. Any of these are individually controlled.

Similarly there are individual settings for the 'assignee' and for the 'administrators' for issue creation, update and closure.

The next place to look is for the individuals settings in the 'people' tab to be checked to see if they are individually configured to receive email notifications.  If they are set to not receive email notifications then except in a few special cases it is not surprising if they do not get a message.  The precise setting will vary for every user and whether it is set or not will be dependant upon the component default setting and whether the user has chosen to set the value to yes or no.

If you are still experiencing problems then we need to look at these settings to see if there is an inconsistency which we have overlooked in the coding. Be aware that there are also a few inbuilt rules that prevent email notifications being sent under certain circumstances, as explained in the documentation.

The main ones are briefly:

1. An assignee email is not generated if the assignee is the one creating the issue.

2. Issue administrators are not sent emails if an issue administrator is creating an issue.

3. If an issue administrator is closing an issue then issue administrators are not sent an email.

4. If an assignee is closing or updating an issue they are not sent an email.

5. If an issue administrator is updating an issue, then issue administrators are not sent emails.

If you are a non-English site and language translations have been performed upon the email templates, ensure that the email template names (i.e. ass_new, user_new etc.) are not translated. It is fine, and expected that the email template title and the template body are translated but not the template title. The reason is because the email template name is used internally to construct the outgoing emails. If the email templates names are changed (i.e. translated) then the email notifications will not work.

For this self same reason the email template names should always be left alone.  Changing them will result in the template not being found and hence no emails, of that type would be despatched.

There are also a few mail settings under the CRON options tab. These are used for the fetching of emails (something that Joomla does not do), and NOT for the sending of email messages. Unless you are also intending to 'fetch emailed issues' then these do not need to be entered.

 

The short answer is YES. The long answer is probably, but it depends more upon your setup. The subject is quite involved and this can only be a quick overview since the subject is covered in great detail in the User Guide, which it is strongly recommended is read before attempting the setup. It is available on the web site either as a downloadable PDF or as viewable web pages.

As a general overview:

The Joomla system itself does not understand the receipt of email, so it is necessary to set up a scheduled task (covered in the manual) using something like 'cron' on Unix systems, to connect to a mail server and fetch the emails. Basically this is a simple shell script consisting of a few lines. The scheduled tasks either calls a specific web page on the front end (pseudo cron), or better yet calls a PHP CLI script (supplied and installed as standard) which does the mail fetch. Not all web hosts allow the use of PHP CLI binaries. There are examples of both in the manual.

For this one will probably want a specific email account/address on a mail server that is accessed so that only emails concerned with 'Issues' are retrieved.

Once retrieved the email is inspected (by the issue tracker component code) and depending upon criteria and what is contained in the message, is accepted and entered into the database as a 'new' issue, where it does the usual things like assigning people, triggering emails etc. There are checks for SPAM etc. as with any entered issue. There are also entries may in the Issue Tracker log (accessible from the back end control panel), IF logging is turned on, which is recommend especially during testing, and probably afterwards as well.

The email fetch will also mark to the mail server that it has fetched the email so further attempts do not fetch the self same email over and over again.

There are also third parties that offer services that can call a specific web page at scheduled times, some free, some will incur a cost.

It is also possible to receive email responses to existing Issues but be sure to read the caveats and understand the principles before using this in particular. It needs to identify the existing issue and filter out any 'duplicate' information from a response when a person does a 'reply' to a sent email so that it 'knows' it is a reply and not a 'new' issue being raised.

It works very well for the raising of issues. The responding to issues also works although due to the vast number of mail clients and their varied ability in replying to emails makes the updating of existing issues very complex. i.e Outlook, Thunderbird etc..., the list is endless. The rationale is covered in the documentation and hopefully all the bases are covered, or at least the most common ones.

 

This is definitely one of the most common error message you will see if you have trouble sending e-mails using your server and unfortunately, this error message does not tell you how you can solve the issue.

Technically, the phpMailer library (a famous php library to send e-mails, used by Issue Tracker and Joomla) tries to send a message using the php mail() function and the php mail() function returned "false".

Note that Issue Tracker notifications are constructed from tags that include information extracted from the Issue that the notification is connected with. This means that the problem may not be with the mailer itself but possibly the information contained within the Issue itself. In particular the subject line itself may cause problems.

Based on experience this might be caused by:

• You are on a local server (using WAMP for example):

Most of hosting company will allow you send a certain number (X) e-mails per hour. If you go over that limitation, the mail server will refuse to deliver more e-mails and will display this error message. So for example if you successfully sent a number of e-mails and you can't send e-mails any more, then this is probably what has happened and you should first wait one hour to deliver more e-mails and also may want to review your hosts mailing limitations, especially if this is a busy site and you are sending a lot of notifications either solely or with other components sending e-mails such as newletters.

 

Don't worry you are probably not alone. As the component has grown and more and more requests for features has increased there have been more options introduced to meet these requests. We have taken a lot of time to create some extensive documentation, which we make available both as normal web pages, or as a downloadable PDF file. The various options are fully described in the documentation.

 

This component has proved very useful internally within the company and there a few planned enhancements particular involving graphical reports. We are also considering making the component multi-lingual, such that it can handle more than one language for issues within the system. If you have any specific requests please raise a forum entry or raise an issue on our website (there is a link in the 'Support' section of the Control Panel where the component is installed on your site), so that it may be considered for inclusion in any future plans. Registered users can use the menu item on the User's menu once they have logged in.

 

There are times where Issue Tracker does not install the sample data, or a stored procedure which was working perfectly fails after a database upgrade, or a formally working INSERT statements starts giving errors such as a Thread stack overrun error

Typically the error message would look like the following:

Error Code : 1436

Thread stack overrun: 6444 bytes used of a 131072 byte stack, and 128000 bytes needed. Use 'mysqld -O thread_stack=#' to specify a bigger stack.

The actual values in the error code will differ depending upon the version of the MySQL database in use and the various defaults that may be applied upon your system.

According to the MySQL manual "The default (xxxKB) is large enough for normal operation. If the thread stack size is too small, it limits the complexity of the SQL statements that the server can handle, the recursion depth of stored procedures, and other memory-consuming actions".

To resolve this issue you need to increase the default value of parameter thread_stack, either by issuing the command as specified in the error message, or in the my.cnf MySQL configuration file increase the thread_stack value to something larger such as 256K or 512K. The value can not be increased to a value larger than that specified in the operation system.

 

Problems have been seen using the component sh404SEF and the pagination display of list screens from Issue Tracker on the front end of the site.

The problem is caused because the sh404SEF component has created URLs for Page-2, Page-3 etc which are then referenced in the pagination module, causing the wrong page to be displayed. i.e. If the pagination limit is set to value of 5, then page-1 will contain records 1->5, page-2 records 6->10, page-3 records 11-15 etc. If one then changes the pagination limit to 10, the records should be page-1 1->10, page-2 11-20, etc. However the link in the list page footer shows the link as page-2, and when one clicks on the link it displays the 'original/earlier' page-2. i.e. records 6-10. This is obviously incorrect.

This is not a problem with the issue tracker pagination code per se, but it is a problem with the way in which the sh404SEF URLs are created from the component.

Tests have shown that if the sef_ext code is modified to retain the 'limit' and limitstart' variables then the correct pages are displayed, once the existing entries in sh404SEF have been removed.

So from Issue Tracker release 1.3.1 these two variables will be visible. In this way the pages displayed will be correct and any page cache in use on the site will also work correctly.

It is however necessary to clear out the entries that may have been stored in the sh404SEF tables for the 'page-x' variables so that they are not reused, and hence defeat the purpose of the change.

 

These error messages have been seen when attempting to install the later versions of Issue Tracker on releases of Joomla prior to 2.5.6.

The problem is caused because Joomla 2.5.6 changed to using 'true' MVC structures for the underlying framework. They took the opportunity to add 'legacy' classes since not everyone could convert their components immediately. Indeed even the supplied components make use of the 'new' Legacy classes.

The problem is caused by using a later version of Issue Tracker (converted to use the legacy classes) on the early versions of Joomla (below 2.5.6).

The solution is to upgrade the version of Joomla to the latest version which will not only resolve the problem but provide you with all the latest Joomla security fixes at the same time.

 

A number of SQL errors may occur when installing the component that relate to database privileges. Typical errors are as follows:

1227: Access denied; you need (at least one of) the SUPER privilege(s) for this operation

1419 You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

These error messages can all cause the installation of the component to fail on versions of Issue Tracker prior to release 1.6.3.

Release 1.6.3 introduced some additional checks to determine whether the database has 'binary logging' enabled and if so, will then check for the 'SUPER' privilege or the 'log_bin_trust_function_creators' database setting before trying to install database triggers or routines.

The installation will now complete if the required database permissions are not present. It does mean however that certain features of Issue Tracker would not be available.

If the TRIGGER privilege is missing then the 'Advanced Auditing' feature, and the back up mechanism for basic auditing will not be available. The component will still work but the basic auditing will rely only upon the component PHP code. External changes to the data, such as via MyPHPAdmin will not be recorded.

If the 'CREATE ROUTINE' privilege is missing then 'Sample Data' will not be present and it will not be available to install to test out the component. This is considered trivial.

{\accordions}

Basic support hours are Monday through Friday (9:00 AM - 16:00 PM BST).  We can not guarantee support outside of these times (over the weekends, public holidays...) unless specifically contracted. Thank you for understanding.

Contracted support customers and users will have specific contact details, the following applies to support of any Macrotone products made freely available.

 

 

Please make sure that your question is not answered in the documentation and/or our troubleshooting FAQ's before submitting an issue/subscribing for support. It will assist us and help you save time!

 General Support FAQ

Contact form

The contact form can be used by both registered and unregistered users.  Response time will be dependant upon staff availability and contractual commitments.

Open contact form in new window