formulize roadmap

Show specific issues for this release

Hide these issues

• 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.
• 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.

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?
• 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.
• 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...
• Improved reporting features with graphs, etc (Formulize) — There could be a lot of graphical features that might get added in. A good PHP graphing library for doing this is http://pchart.sourceforge.net/
• 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.
• 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.

Show specific issues for this release

Hide these issues

• Add distinct display controls per element for the form and the list views (Formulize) — Right now, you can control whether a group sees an element, but that control extends to the form and to the list. It would be useful in some situations to have independent control over whether a group can see an element in the form, separate from whether they can see the element in the list too, and vice versa
• Merge Pageworks into Formulize as a custom screen type (Formulize, Pageworks) — Pageworks pages are essentially custom screens for Formulize. They could all be merged into the screen system as a "custom" type of screen.
• Need to add the ability to have a reset button to each form (Formulize) — Details are here:
  http://www.freeformsolutions.ca/en/node/538
  This may require the full screen type for regular forms, so that the reset button can be specified.
• Update internal references within a cloned form after it is created (Formulize) — Forms can include references to elements in themselves, such as the starting elements for grids. When a form is cloned, all those references remain the same in the new form, and that means they're all broken. We could update all those references by mapping the old/new element pairs and updating the references in the new cloned form.
  This is much easier now since we're tracking some of this information already for synching linked forms after cloning.
• Admin features that refer to groups should allow reference to group lists (Formulize) — Many admin features let you pick groups. This is a problem when new groups are added to the site. If these lists let you pick grouplists as well, then updating the grouplists would be all that is required when new groups appear. The logic for these features would need to be updated to unpack the grouplists into their groups, but that could be nicely encapsulated in a function, so it would be a one line change to everywhere the groups are read.
• Grouplists should be stored in the main permission table (Formulize) — Instead of being stored in our own special table, we should put the group lists in the main permission table. It would be easier for wholesale updating of permissions across the site in the future.
• 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.
• Fix the capturing of filter terms that use OR when they are being isolated for use in count and calculation queries (Formulize) — The data extraction layer in Formulize is pretty complicated, so that it can handle any kind of join situation. The construction of the WHERE clauses for these queries, based on the filters that users type in, is even more complicated. In some cases, because of possible one-to-many relationships, certain kinds of filters that would normally be handled by a regular WHERE clause, must instead be handled by an EXISTS clause inside a WHERE clause, or they need to be broken up by form, or other such specific variations.
  There is one complexity that is currently not handled, and that is when the user specifies "OR" filter terms on two or more fields, and at least two of those fields are not on the same form. There is an extensive comment about this in the include/extract.php file, talking about "oneSideFilters".
  The abstraction of the data extraction layer needs to be extended to the point where it can handle this possible, but rare, situation.
  The effect of this shortcoming, is that right now, calculations that involve such a query may produce incorrect results.
• Add column awareness to the getData function so queries can select only the fields that are in use (Formulize) — When the getData function does a query on the database, all fields in the entire form are gathered. This is overkill. We should optimize these by including only the necessary columns in the select statements.
• Correct logic in getFirstEntryForUsers method in data handler (Formulize) — Right now, this method checks the creation uids in the data tables to see which entry belongs to the users. But in situations where this method is used, the entry_owner_groups table should be consulted instead. All the places where this method is used should be checked and potentially rewritten, to take advantage of the superior architecture of using the entry_owner_groups table, so creation uids' group memberships don't become relevant ever.
• Print All button on multipage forms needs to be based off of each page, not the entire form (Formulize) — Sometimes, not all elements are included in the multipage version, or at least in a particular multipage version of the form. And sometimes the elements appear in the multipage in a different order form how they appear in the form itself. So the print all button on the multipage form needs to take into account the order of all elements on all pages, and print that, not just all the elements in the form.
• Force source elements for framework relationships to be required (Formulize) — If you try to submit a form that is being displayed as part of a framework, and the important source value element in that form is empty, then the linkages in the framework will not be populated properly...source elements should be forced to be required, regardless of whether the user has made them required or not. This is necessary to ensure data integrity really.
  People can workaround the issue though, if they simply set the elements that should be required, as required.
• Subform UI needs to enforce required fields (Formulize) — Right now, required fields in subforms are not enforced. Oops.
• Add a suffix option to the number formatting feature (Formulize) — This would be useful for % signs or other things like that. It would require a new property of textbox and derived value elements, and then awareness of that new value built into the number formatting function in include/functions.php
• abstract element-related code to single class per element (Formulize) — This will have obvious uses for outside developers, and make internal maintenance somewhat easier.
• Make order in which subform entries are listed be configurable (Formulize) — Right now, they are listed in order of entry_id, but which field is the default sort order should be configurable in the subform element settings, and also the user should be able to click a column heading to change the sort order.
• Add metadata fields to the possible fields that linked selectbox limiting conditions can be based on (Formulize) — Right now, you can only limit linked selectbox lists based on elements in the same form as the target element that is the source for the values in the list. You should be able to limit based on the four metadata fields for that form as well, ie: User who created the entry
• Changes to varchar and char lengths should trigger alter table statement (Formulize) — Right now, if you have an element set to use the datatype varchar and you change the length, that will not actually change the database. This needs to be fixed so it will change the database.
• Validate what users type in elements for specific values (Formulize) — Users might be supposed to enter 1-300 but not higher or lower numbers in a textbox. Other specific values might be required in other situations
• 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.

Show specific issues for this release

Hide these issues

• 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
• Consider inversion of the permissions interface (Formulize) — It may be possible to set permissions across multiple forms, in the same way that you set permissions across multiple groups now. This will need to be thought about carefully in order to come up with the right interface.
• 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.
• Update all code to use preg instead of ereg (Formulize, Pageworks, iMenu, Registration Codes) — See the table here...all ereg references should be updated.
  http://www.ibm.com/developerworks/opensource/library/os-php-future/
  Also this has info:
  http://stackoverflow.com/questions/375563/why-wont-this-standard-reg-ex-work-in-phps-ereg-function
• Ban periods as characters in element handles (Formulize) — PHP swaps out periods for underscores in variable names, in certain circumstances. Therefore, element handles, which get used as part of variable names in some places, should never have periods in them, since it prevents proper identification of which element that is, when the period goes missing after PHP swaps in an underscore.
• 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 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.
• Make date formatting a configurable option (Formulize) — New XOOPS and ImpressCMS allow for this. We should integrate with that and let users have whatever date format they want. We still need to support a default non-date value though. More discussion here: http://www.freeformsolutions.ca/en/node/762

Show completed issues, already in SVN

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.
• 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 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.
• 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.

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.