formulize roadmap

Show specific issues for this release

Hide these issues

• The list of entries interface could be made way more interactive, with draggable columns, and "in-place" changes to screen-level config options, such as whether a column shows values or elements, the number of records per page, etc. (Formulize) — Essentially, most options that screens give you for controlling the list, they could be added to a revamped list-of-entries interface, so you could model list of entries screens on the fly...turn off the scrolling box, change the rows per page, etc, just as easily as you change columns right now.
• Improve calculations specification interface (Formulize) — The calculation interface is quite clunky. But it has a ton of options, so it's a hard redesign. Some kind of in-place specification of the options would be better, if possible, maybe a progressive thing where you click a column and get a popup to pick the calculations you want. Then on the calculations page, you can click the result to change it's grouping option, exclusion list, etc?
• Import/export of entire applications, all forms, frameworks, permissions, screens, etc (Formulize) — If you could package up entire applications that you had created, and export them and import them to other systems, then Formulize would become a platform, and not just a development tool.
• Add a graphical form layout designer (Formulize) — Being able to visually control the layout of forms would be a big plus to designers. This would be like having point and click control over what you currently must do through Pageworks and the displayElement function
• Complete encryption feature, so it works fully with calculations, and other operations (Formulize) — Not all the processes for generating database queries are aware of the encryption property of elements. Grouping calculations by an encrypted field is currently not supported, nor are some other cases.
• Support framework relationships based on more than a single field (Formulize) — Right now, all frameworks contain relationships between forms that are based on one field only. We should support multiple field relationships. ie: joins based on more than one key field
• Allow restriction of number of entries based on values in a field (Formulize) — Right now, Formulize enforces one entry per user, or per group, and that's all. We could support only one entry per user that has value X in field Y, ie: only fill in one activity report with the value of the month field is "January". If another activity report for January is submitted, it will be rejected, because only one entry with that value in that field is allowed. In some ways this is a special case of required field. It's a limit on the uniqueness of a certain field.
• Include a real web services layer in the API (Formulize) — The Formulize API is designed around use on the same server as part of the PHP stack. It would be useful if there was a web services based API that could be used by other systems to interact with them more easily.
• Improve the workflow for creating relationships (Formulize) — Relationships are part of how people think about creating subforms and other actual things in their application, not an abstract concept. We should somehow merge their UI with the screen admin page? And or the subform creation UI? Or have a whole how-the-forms-are-related drag and drop thing on the forms list for each application?
• Enable relinking of cloned linked selectboxes to other cloned forms (Formulize) — This feature existed in version 3, but was lost in the version 4 update, due to UI changes. The functionality still exists in code, it just needs to be renabled, probably by writing some kind of flag into the markup when the form list is drawn and triggering a javascript box or some other popup with choices, so the user can pick which other cloned form to relink this form's elements to.
• Have selectbox lists refresh in realtime (Formulize) — It would be nice if selectbox lists did some kind of asynchronous call back to the server to update their options (if they were linked to another form) so that newly created entries showed up without having to reload the whole form
• Let the webmaster control the default columns and sort order per screen, as a config option, instead of having to make a saved view (Formulize) — Right now, you have no control over the sort order except through a saved view, and the default columns are a form-wide setting, not part of the Screen config at all. Making Saved Views is a sledge hammer approach to controlling these basic options.

Show specific issues for this release

Hide these issues

• Ajax features in the display and saving of forms (Formulize) — Stuff like auto-completes, selectboxes that are linked together without page-reloads (ie: country/state/city, etc), saving without reloading the page maybe...
• Ability to use a text editor for textarea elements (Formulize) — If Formulize is being used in a content management situation, being able to use a text editor like TinyMCE, or whatever the XOOPS/ImpressCMS installed editors are, would be neat.

Show specific issues for this release

Hide these issues

Show completed issues, already in SVN

Hide completed issues

• Need to manage indexes in the datatables through the Formulize admin UI (Formulize) — With proper datatyping comes the need to control indexes, to optimize performance of joined tables. This should probably be made available through the framework interface perhaps.
• Make linked selectbox entries fully numeric in the database when the selectbox is a dropdown list (Formulize) — Linked selectboxes use a comma separated format to store references to other entries. But this is not indexable as a number field in the database, due to the presence of commas. When a selectbox is just a dropdown list, allowing only one selection, this field in the database should be made numeric so it can be indexed that way and provide fast joins.
  The extraction layer should be checked to ensure that joins in this situation are done with = and not LIKE.
• Link from form/list page to the admin page(s) for the form (Formulize) — Right now, you have no direct way of going back and forth from a form's properties to its actual user-side view. Links from the form to its properties would be helpful. These could be based on the edit form permission.
• Make the form elements show as disabled when the user cannot save (Formulize) — Right now, the form shows as a form, which is confusing, even when the user cannnot save.
• {ID} not picking up the next autoincrement (Formulize) — The value for an {ID} keyword is determined by looking at the next ID in the form and adding 1, but it should check the next autoincrement value from MySQL, or better yet, check the written ID after the fact. This causes 1 to be used as the {ID} value when the table is empty, regardless of the actual autoincrement value.

Show issues completed for this release

Hide completed issues

• Make changes to question options also change existing data users have entered (Formulize) — Right now, when options for radio buttons, for example, are edited, the existing data that has those values is not modified. The challenge here is differentiating between re-ordering of options vs. adding or inserting new options. It's a UI problem, plus there needs to be additional logic in the system to handle the changes in the database.
• Have enforcement for unique values in textboxes (Formulize) — The SVN code now has this feature, although it only checks for global uniqueness. It would be fairly simple to change it so that with more configuration options, users could specify uniqueness only within certain groups, for example.
• Deprecate framework handles (Formulize) — Now that elements have native handles, we can do away with framework handles, but the code dependencies this will affect are huge. Also, we need to introduce form handles as well, to totally deprecate framework level handles.
• Revamp administration UI to match workflow of using Formulize (Formulize) — The interface is very point-to-point right now, you have to know what you're doing, know what you need and go to that part of the interface in order to do it. The interface needs to present options to the user in a more logical way, given the typical use cases for how Formulize is used to make applications.
  The new interface needs to group forms together into applications, and provide links to view each form and screen directly (like the view this form link does now).
  And it needs to present all options for a form in a nice tab-like interface, ie: collect together permissions, screens, frameworks, menu options (yes, integrate with iMenu), element editing, all from a single UI per form.
• Add regular forms as a screen type (Formulize) — Right now, only multipage forms can be specified as screens. There is no screen type for a plain non-multipage form. That should be easy enough to change (and could include the logic for reset buttons).
  Regular form screens should also be specifiable as a/the default screen. More than one default is possible, they should be ranked somehow, and users get the first one that they have permission for.
• Create a standalone installer (Formulize, ImpressCMS, XOOPS) — You need to be able to download Formulize and install a working system in one shot
• Preserve data types when cloning forms (Formulize) — Right now, when forms are cloned, their data types for all fields are 'text', regardless of the data types in the database on the original form. The cloning process should be aware of the original datatypes and preserve them. This will require making some kind of element map that shows what the original element (and data type) was for each of the elements in the new form.
• Make text left justified and numbers right justified in list of entries tables (Formulize) — This could be easily done by checking is_numeric on the value being drawn in a cell prior to the number formatting step.
• Make hard coded OR in multiple per group filters into a user-configurable option (Formulize) — Users now have have the choice of whether multiple per group filter selections are treated as having an implicit AND or OR. It used to be hard coded to OR.
• Make automatic conversion of linked/associated values into clickable links, into a configurable option instead of automatic (Formulize) — If you look at a list that contains linked selectbox values, then those values will be clickable. This behaviour is not universally desired. It should be configurable on or off (default off) in the element properties.
• Force values in textboxes to be unique across all entries (Formulize) — For textboxes, there is now an option to validate what the user typed by checking to see if that value already exists in the database. This lets you require and enforce unique values in textboxes.
• Encryption of values in the database (Formulize) — There is now an option to encrypt the values users enter into the database, so they are not visible as plaintext. This feature currently does not work in conjunction with all calculation features and other features, but does work with all searches.
• Added Lockdown feature, so no changes are possible to forms through admin UI (Formulize) — The lockdown feature supports situations where you have set a form the way you want to have it set, and no one, not even the webmaster should be able to make changes afterwards. This is useful in conjunction with the encryption feature, in situations where the integrity and privacy of data needs to be enforced.
• Advanced groupscope controls, to declare which groups other groups can see (Formulize) — Now you can specify that for a certain group, the scope of entries that are visible to those users, should be based on some specific other group. Normally, "groupscope" means "your own group" but now it can be arbitrarily assigned.
• Per-group-filters controlling what people can see (Formulize) — Now you can specify that certain groups have fundamental limits on what entries they can and can't see. This is useful if certain groups in your workflow should only see entries in a form after the "approved" flag has been set to "yes" for example. Now you can specify that kind of condition as a property of the group itself, and you don't have to setup that filter throughout your application in multiple places.
• Improved handling of derived value formulas so you can use " in them (Formulize) — Double quotes used to be not allowed in derived value formulas, since they are used to refer to form elements. Now you can include double quotes around text that does not refer to an element, and the formula will work.
• Relink selectboxes in cloned forms so they point to other cloned forms (Formulize) — If you have a form that contains a linked selectbox that points to another form, you can now clone the two forms and have the linked selectbox in the cloned form point to the newly cloned counterpart. This relationship is preserved in the cloned data that users have entered as well as in the form definitions.
• Conditional elements - control whether elements appear in a form based on the value of other elements (Formulize) — All elements can now be set to only appear in a form when certain conditions are met, based on the values in other elements in this the entry.
• One-entry-per-user setting now respects anonymous users, sort of (Formulize) — Using cookies, anonymous users each get an entry of their own in forms that are set to one-entry-per-user. They used to all share the same entry, which was very strange.
• Add autocomplete boxes for use when selectboxes have lots of options (Formulize) — When there's more than 30 options in a linked selectbox, it would be nice if you could just have an autocomplete box that let you type in what you wanted, instead of having to pick the item.
• Bounding box on selectbox options moves down as new options are added to the list (Formulize) — On the admin side, when creating options for a selectbox, the fieldset box is tied to some element that is moving down as new ones are added to the list (when the user clicks Add 1).

Show issues completed for this release

Hide completed issues

• Ensure cloned forms get the same permissions as the original forms (Formulize) — Right now, cloned forms have no permissions set on them at all. They should have permissions set on them that match the permissions of the original form. Changes need to be made in admin/formindex.php in the cloneFormulize function.
• Properly strip slashes in names of saved views (Formulize) — Currently saved views with apostrophes in the names get slashes in them. This is a trivial thing to fix. It should be handled in include/entriesdisplay.php, near the top where the saved views are inserted into the DB.
• Ensure "tableforms" are working as expected (Formulize) — The "reference to a datatable" feature has not been tested in a long time. It needs to be checked to make sure all the recent changes haven't broken anything.
• Add security token to the display of the printview version of the form (Formulize) — Right now, only form permissions secure that page, but adding the security token would be good.
• Add quicksearch help to the default list of entries interface (Formulize) — The standard help popup should be available through some UI link. But what should it be/look like?
• Add note to the settings page explaining how anonymous users don't interact well with the "one entry per user" setting (Formulize) — Since anons all have user id 0, they are treated as the same user, so the one entry per user setting doesn't really apply to them.
• Add handling for different data types in the database layer (Formulize) — Right now, all fields in the database are "text". They can be changed directly in MySQL if the developer wishes, but control of this should be extended to Formulize. Challenge is to be aware of whatever typing has already been put in place and using that as the default for the UI, rather than storing this status in some other place.
  When this is complete, we should be able to search for 14-18 in a text field (ie: an age range expressed as text) and it should not evaluate mathematically. Also, sorting on fully numeric values should work as well. It does not in all cases right now.
  Also, we need to beef up the handling null values. Formulize just puts "" in the database right now, but that can have bad consequences, for example when converting those values to a date type, they would all become 0000-00-00. So when converting to date, for instance, 0000-00-00 should be switched to null.
• Allow HTML from DB setting is reported to not be saved properly (Pageworks) — This setting for each page should be specifiable on every page and should save. Some investigation is necessary.
• Add a link from the admin side to the "manage reg codes" page (Registration Codes) — Right now, the user side manages the registration codes, and the admin side does not. Need a link from the admin side to the user side for ease of navigation.
• Preferences needs to be a link at the top of each admin page (Registration Codes) — Registration Codes has no in-page navigation to its preferences. This can be changed.
• Ensure latest French translations are included (Formulize) — Several new French translations have been done by various participants. They all need to be collated and added to the codebase.
• Add an upgrade script and config options for number formatting (Formulize) — Now that number formatting is possible, we need some config options to control this, as well as some way of applying the new formatting to existing values intelligently in the patch process.
• Ensure all grouping text is translated, even when drawn from multiple value elements (Formulize) — When grouping is done by multiple value elements or translated elements, the trans function is not always applied, and the multiple value elements are not always broken up. Need to ensure they are in all cases.
• Optimize the list of entries interface so it takes advantage of the 3.0 data structure (Formulize) — Now that data is stored in a one-table-per-form structure in the database, all kinds of optimizations and changes to how lists of entries are generated, can be realized. Queries for lists, calculations, and exporting all need to be rewritten to take advantage of these features.
• Make it possible to select which screen should be used as the data entry form for a particular list of entries (Formulize) — When using a specialized list, the developer may not want the default form view to be used as the data entry screen. The list of entries screen type needs to support choosing which other screen, or pageworks page, should be used when the user clicks though to an entry.
• Major improvements to list rendering speed (Formulize) — The new data structure helps make lists load faster, but there were also many things in the actual preparing and drawing of lists that could be speeded up and were.
• Add standard deviation and percentiles to the averages calculation (Formulize)
• Major calculation improvements, including multiple levels of grouping and custom exclusion lists (Formulize)
• Add number formatting options to control the appearance of numbers on screen (Formulize)
• Support for dashboarding - add API function to retrieve raw calculation results from a saved view (Formulize) — This allows developers to call a saved view and then display some or all of the calculations that are part of that view. It allows for custom design of dashboards.