alanstylez
Member
My company was recently audited and one of the issues that came up was in regards to 'document control'... i.e. the ability to track changes to forms, form submissions, etc. Now, in the case of company policy and procedures, which are written as Joomla content (articles), the version tracking system that is accessible through the 'Versions' button, however, this function does not extend to other 'content', such as Fabrik form submissions, elements (questions), or introduction/footer text. Some of this can be addressed by adjusting access levels, while some cannot. Here's an example: Registered users need to be able to submit their forms. Registered users need to be able to update the information submitted on their forms (i.e. - if they move, they need to be able to update their address, or if they have information updates from their doctor such as the day they plan to deliver their baby, they need to be able to change their previous answers on our forms). However, some information changes should be deemed unacceptable, such as if they originally completed the informed consent and later went back and removed their consent or altered their signature. Why they would do this, I don't know, but we need the technical ability to track ALL changes so that if one change were made with mal-intent, we would be able to prove it.
So, the first potential solution to this problem, I considered altering the file structure and having a time-stamped .pdf file rendered and stored, but this would create a number of issues, including slower load times, exponential increase in storage space required to accommodate .pdfs for every submission of every form, and user-access issues, not to mention the challenge in formatting all of the rendered .pdfs to reflect each of the forms (i.e. - my previous issue with yes/no answers, other fabrik users issue with the digsig element, and I'm sure many others).
My second potential solution to this problem was a complete integration of Joomla and Fabrik, achieved by creating Lists of the core Joomla tables, such as _content, _content_types, _ucm_content, _ucm_base, and _ucm_history, creating a bunch of database join elements, and somehow creating a 'Versions' button that would appear on every table, every form, and every element. Needless to say, this project quickly became overwhelming and is more the responsibility (or opportunity) for the master coders who work as Pollen8 employees (although I would be happy to share the progress I made with the Joomla-Fabrik core integration).
The third potential solution I came up with is probably the most reasonable, therefore it is the one that I have spent the most time with and is the closest to completion. I figured, since the Joomla core Versions button works well for articles created and modified over time, why don't I just use the 'article' plugins for fabrik forms and lists. So, I set out to create categories and sub-categories for every form with which I need to track changes. One of the first things that I realized was that it is somewhat tedious to create elements for each form that covers each of the fields required by the fabrik_form/article plugin (category, reference element, Title, Author, Publish up, Publish down, Published, Featured, Meta Key, Meta desc, Tags, Intro Image, and Main Image), not to mention creating an article template with place holders for each of these forms. This process was made somewhat easier when I realized that I could use List / Data / Joins to the _content table to add all of the relevant fields, but I am still getting caught up passing some of the variables that are contained within the 'array' fields, i.e. params or attribs.
The primary technical problem with this approach is that even though articles are being created which contain the answers of the form submission, the fabrik_form/article plugin (or my configuration of it) is not recognizing the difference between a new form submission and an update and is therefore creating new articles every time, which makes the 'Versions' button useless. I had a glimmer of hope after discovering that the fabrik_list/article plugin was supposed to create a button that resulted in an article update, but I never figured out when or where that button was to show up or how it worked. Again, I'm not sure if this is because this plugin has not been updated to reflect some change in the code, or if I am configuring it wrong, but a quick look at the database seems to show that all of the relevant variables are getting caught up in the 'IntroText' column of _content and not getting distributed to fields like 'title'.
Needless to say, the documentation surrounding these two plugins is useless (http://fabrikar.com/forums/index.php?wiki/article-form-plugin/&redirect=form-article-plugin-tutorial and http://fabrikar.com/forums/index.php?wiki/list-article-plugin/)... maybe now is the time 'todo.....' Also, I am somewhat surprised that a forum search did not turn up any previous issues related to the article plugins, version tracking, or document control. Maybe people just don't realize the power of the 'Versions' button?
So, I have once again paid for membership support, this time at a much more sustainable rate, in an attempt to engage both the community and the fabrik wizards to see if I am approaching the document control issue in a direct fashion and to address the bugs in the article plugins. BTW, I just noticed that this type of thing is on the roadmap for Fabrik 3.5, due in August 2015, but I really can't wait that long to pass my audit. Also, I noticed that the Fabrik Wiki has some type of version control, which I discovered when I accidentally edited the digsig element wiki (http://fabrikar.com/forums/index.php?wiki/digital-signature-element/). How does that work and can we apply those lessons here, or is that from Kunena or some other 3rd party?
Looking forward to hearing your responses and suggestions.
So, the first potential solution to this problem, I considered altering the file structure and having a time-stamped .pdf file rendered and stored, but this would create a number of issues, including slower load times, exponential increase in storage space required to accommodate .pdfs for every submission of every form, and user-access issues, not to mention the challenge in formatting all of the rendered .pdfs to reflect each of the forms (i.e. - my previous issue with yes/no answers, other fabrik users issue with the digsig element, and I'm sure many others).
My second potential solution to this problem was a complete integration of Joomla and Fabrik, achieved by creating Lists of the core Joomla tables, such as _content, _content_types, _ucm_content, _ucm_base, and _ucm_history, creating a bunch of database join elements, and somehow creating a 'Versions' button that would appear on every table, every form, and every element. Needless to say, this project quickly became overwhelming and is more the responsibility (or opportunity) for the master coders who work as Pollen8 employees (although I would be happy to share the progress I made with the Joomla-Fabrik core integration).
The third potential solution I came up with is probably the most reasonable, therefore it is the one that I have spent the most time with and is the closest to completion. I figured, since the Joomla core Versions button works well for articles created and modified over time, why don't I just use the 'article' plugins for fabrik forms and lists. So, I set out to create categories and sub-categories for every form with which I need to track changes. One of the first things that I realized was that it is somewhat tedious to create elements for each form that covers each of the fields required by the fabrik_form/article plugin (category, reference element, Title, Author, Publish up, Publish down, Published, Featured, Meta Key, Meta desc, Tags, Intro Image, and Main Image), not to mention creating an article template with place holders for each of these forms. This process was made somewhat easier when I realized that I could use List / Data / Joins to the _content table to add all of the relevant fields, but I am still getting caught up passing some of the variables that are contained within the 'array' fields, i.e. params or attribs.
The primary technical problem with this approach is that even though articles are being created which contain the answers of the form submission, the fabrik_form/article plugin (or my configuration of it) is not recognizing the difference between a new form submission and an update and is therefore creating new articles every time, which makes the 'Versions' button useless. I had a glimmer of hope after discovering that the fabrik_list/article plugin was supposed to create a button that resulted in an article update, but I never figured out when or where that button was to show up or how it worked. Again, I'm not sure if this is because this plugin has not been updated to reflect some change in the code, or if I am configuring it wrong, but a quick look at the database seems to show that all of the relevant variables are getting caught up in the 'IntroText' column of _content and not getting distributed to fields like 'title'.
Needless to say, the documentation surrounding these two plugins is useless (http://fabrikar.com/forums/index.php?wiki/article-form-plugin/&redirect=form-article-plugin-tutorial and http://fabrikar.com/forums/index.php?wiki/list-article-plugin/)... maybe now is the time 'todo.....' Also, I am somewhat surprised that a forum search did not turn up any previous issues related to the article plugins, version tracking, or document control. Maybe people just don't realize the power of the 'Versions' button?
So, I have once again paid for membership support, this time at a much more sustainable rate, in an attempt to engage both the community and the fabrik wizards to see if I am approaching the document control issue in a direct fashion and to address the bugs in the article plugins. BTW, I just noticed that this type of thing is on the roadmap for Fabrik 3.5, due in August 2015, but I really can't wait that long to pass my audit. Also, I noticed that the Fabrik Wiki has some type of version control, which I discovered when I accidentally edited the digsig element wiki (http://fabrikar.com/forums/index.php?wiki/digital-signature-element/). How does that work and can we apply those lessons here, or is that from Kunena or some other 3rd party?
Looking forward to hearing your responses and suggestions.