- Jul 16, 2012
-
-
Peter Rotich authored
-
- Jul 09, 2012
-
-
Jared Hancock authored
-
Jared Hancock authored
And rearrange files to work with the new layout for the finalized upgrader
-
- Jul 08, 2012
-
-
Jared Hancock authored
-
- Jul 07, 2012
-
-
Jared Hancock authored
The upgrader can't (and shouldn't) do everything necessary to complete an upgrade. The adminsitrator will need to take care of a few extra tasks that are outlined in the UPGRADING.txt file. One of the items includes removing source code no longer used in the 1.7 codebase. A script is shipped (Unix only) that allows an administrator to automatically clean up all old source files that are no longer used.
-
- Jul 02, 2012
-
-
Jared Hancock authored
-
Jared Hancock authored
-
Peter Rotich authored
-
- Jun 30, 2012
-
-
Jared Hancock authored
-
- Jun 26, 2012
-
-
Peter Rotich authored
-
Peter Rotich authored
-
- Jun 23, 2012
-
-
Jared Hancock authored
-
- Jun 18, 2012
-
-
Peter Rotich authored
-
Jared Hancock authored
Allow staff members the ability to select a default paper size which will be used in printing tickets via PDF. In the future, this may be overridden per ticket by a dialog box at print time.
-
- Jun 04, 2012
-
-
Peter Rotich authored
-
- May 13, 2012
-
-
Peter Rotich authored
-
- Apr 28, 2012
-
-
Peter Rotich authored
-
- Apr 26, 2012
-
-
Peter Rotich authored
-
- Apr 25, 2012
-
-
Peter Rotich authored
-
Peter Rotich authored
-
Peter Rotich authored
-
Peter Rotich authored
-
- Apr 23, 2012
-
-
Jared Hancock authored
-
Jared Hancock authored
Add the ability of revoking previous ticket state tracking events when new events are logged for the same ticket. This will allow, for instance, the ability to revert the 'closed' state of a ticket when the ticket is reopened. For statistics tracking, a user could configure whether or not the events should be counted for each event tracked or just the non-annulled events. For instance, if a ticket is closed and reopened several times, only the very last closed event should count toward the statistics for the ticket. Therefore, when a ticket is reopened, previous closed events should be marked as annulled.
-
Jared Hancock authored
-
Peter Rotich authored
-
Peter Rotich authored
-
- Apr 22, 2012
-
-
Peter Rotich authored
-
- Apr 21, 2012
-
-
Jared Hancock authored
And correct several undefined function errors from several source files. So while function names in PHP are considered case-insensitive, it still makes sense to use consistent camel casing for both defining and calling methods. The lint test searches the code base for method calls, and then searches the code base again looking for a function definition matching the name of the function invoked. It's not failsafe, because it doesn't detect the class from which the method should belong, so it's likely to have false negatives. Furthermore, it won't work well for PHP 5 where several classes are built into PHP (and aren't searchable in the osTicket code base). Remove the include/staff/api.inc.php as it no longer appears to be used (and contains references to undefined methods).
-
- Apr 19, 2012
-
-
Peter Rotich authored
-
- Apr 13, 2012
-
-
Peter Rotich authored
-
Peter Rotich authored
-
Jared Hancock authored
Implement attachment migration for attachments Add support for more information stored about the patches in the individual patche files with a Javadoc style syntax
-
Peter Rotich authored
-
- Apr 09, 2012
-
-
Jared Hancock authored
-
Jared Hancock authored
Add SQL patch file and update the main install SQL (MySQL) script to transfer messages, responses, and notes into the new ticket_thread table. For new installations, transfer is not necessary because there are no messages
-
Jared Hancock authored
And make globbing platform independent, which also fixes an issue where not all PHP files were scanned by the phplint tool for uninitialized variables
-
- Apr 06, 2012
-
-
Jared Hancock authored
Track assigned department, team, staff, and help topic when the ticket event occurs. This will greatly help in correlation of various reports and queries Also start plowing the way toward incremental database updates using a patching technique. The hash of the main install SQL script for a respective database will be used to track the signature of the database currently. The signature will be stored in %config::schema_signature, and the main.inc.php script can simply check the value in the schema against the value known to the source code to be the signature the code expects. Should the two signatures differ, patches in the setup/inc/sql/patches folder should exist and be executed to assist in incrementally upgrading the database to the new-current schema version.
-
Jared Hancock authored
-
- Apr 03, 2012
-
-
Peter Rotich authored
-