- Oct 01, 2014
-
-
Jared Hancock authored
-
- Sep 29, 2014
-
-
Jared Hancock authored
* Use the title of "Information" with internal tag of "info" * Add "Visibility" column to UI and retire "Required" and "Internal" columns * Add visibility selection to new fields and show visibility to the user information fields when displayed on the ticket details form * Make the visibility settings translatable * Use constants internally for visibility configuration detection * Use a larger input when managing the information HTML content * Fix validation errors for new fields * Enforce new field name uniqueness * Enforce new field name character validation
-
- Sep 26, 2014
-
-
Jared Hancock authored
-
- Jul 08, 2014
-
-
Jared Hancock authored
-
- Jun 27, 2014
-
-
Jared Hancock authored
-
- Jun 04, 2014
-
-
Jared Hancock authored
Otherwise, no column will be added to the %ticket__cdata table and the ticket queue pages will be crashed (empty).
-
- May 20, 2014
-
-
Jared Hancock authored
-
- May 16, 2014
-
-
Jared Hancock authored
-
- Apr 15, 2014
-
-
Jared Hancock authored
-
- Apr 01, 2014
-
-
Jared Hancock authored
-
- Jan 08, 2014
-
-
Jared Hancock authored
Fix dropping of materialized view when variable name is changed Ensure view exists before merging updates Prevent possible sql injection error in field name used in the materialized view. Prevent possible xss error in the display of the field label and variable name in the admin panel.
-
- Jan 03, 2014
-
-
Jared Hancock authored
Fix adding fields to an existing form
-
- Dec 11, 2013
-
-
Jared Hancock authored
Otherwise, you can't click on the custom form in the table view in order to manage it. Fixes osTicket/osTicket-1.8#276
-
- Nov 27, 2013
-
-
Jared Hancock authored
-
- Nov 26, 2013
-
-
Jared Hancock authored
The upstream ORM method was removed
-
- Nov 25, 2013
-
-
Jared Hancock authored
-
- Nov 23, 2013
-
-
Jared Hancock authored
-
- Nov 16, 2013
-
-
Peter Rotich authored
-
Jared Hancock authored
* Require a label on form fields * Require variable name to be unique per form * Fixup duplicate phone numbers on upgrade
-
- Nov 05, 2013
-
-
Jared Hancock authored
If a form field is required, then a name will be necessary in order to plumb up the API.
-
- Oct 09, 2013
-
-
Jared Hancock authored
-
Jared Hancock authored
Moved to an initial form which specifies the ticket's priority and issue and changed the rendering to render things properly. Now the user can decide where priority shows on the client side, and the priority privacy setting is placed in the dynamic form wizard. The standard form is added to every ticket without option. Extra forms can be defined and associated with help topics which can additionally be added to tickets upon creation. This allows for standardization of the dynamic data location for searches and filtering. Implemented advanced search for dynamic data. Along with reinstating the basic ticket search on keywords Implemented ticket filtering on dynamic data for both keyword searches as well as searches for special fields (drop-down lists, etc.) Phone number for users is now completely optional
-
Jared Hancock authored
Previously, form sections were grouped into form sets for reusability. This patch drops the form sets and makes form sections the new "forms". Eventually a section-header field will be added that technically does not add any dynamic data to the form, but allows for the same feature as having a form set with multiple sections.
-
Jared Hancock authored
*This is a major redesign / rework of the osTicket base* This patch drops the concept of static ticket metadata and allows for an admin-configurable arbitrary data that is attachable to tickets The system is architected such that the base osTicket install now comes with a "default" form that has fields for subject, name, email, and phone number. This form is editable to allow for the addition of arbitrary other fields; however, the basic fields must remain in order to be associated with a help-topic and attached to a ticket. This concept can be expanded to allow for arbitrary data associated with registered clients or ticket thread items. Forms are comprised of sections. Sections have a title and instructions properties and a list of fields. Fields have various implementations to represent different data such as text, long answer, phone number, datetime, yes/no, and selections, and are configurable to define the look and feel and interpretation of the respective form field. Dropdown lists are represented as "Dynamic Lists", which are admin-configurable lists of items. Dropdowns can be optionally represented as Bootstrap typeahead fields. This also adds the start of a simple ORM which will hopefully be expanded in the future to support multiple database platforms. Currently, only MySQL is implemented.
-