Document Control

alanstylez

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.
 
I guess I was so verbose because I wanted to make sure that my reasoning was right and that there isn't an easier way to manage version tracking than creating a article category, article template, fabrik_list/article plugin, and fabrik_form/article plugin for each form. I suppose there will be an easier way when you guys release Fabrik 3.5, but maybe you could share how that will be achieved, so I could get my essential forms working well enough to pass my audit (i.e. - create an Article - Params form, then do an inner-database join from id element to xreference element... or whatever).

So, I applied the GitHub update and the only difference I noticed was that the title of the article now contains the user id (since User ID is selected from the Title field of the fabrik_form/article plugin). But, if I go back to the form, make a change, and click Apply, a new article 191 (4) is created, instead of updating article 191 (3). I think that I need to be triggering the 'if (!isNew)' condition from plugins/fabrik_form/article/article.php, line 156, so that I can use the Versions button on the Edit view to compare (https://nuvacord.net/administrator/...cb668573e70972ffc1211119ebcc=1&version_id=547) to (https://nuvacord.net/administrator/...cb668573e70972ffc1211119ebcc=1&version_id=548).

Hint: I just hacked a workaround by altering the ids of the 'compare' layout/template: https://nuvacord.net/administrator/...b668573e70972ffc1211119ebcc=1&id1=548&id2=547. How to make the Versions button do this?

Again, it could be that I am applying the article plugins incorrectly... I'm having to hack at this problem since there are no useful instructions on the wiki, either here (http://fabrikar.com/forums/index.php?wiki/list-article-plugin/) or here (http://fabrikar.com/forums/index.php?wiki/article-form-plugin/&redirect=form-article-plugin-tutorial). I would be particularly interested in the use of the 'Condition' variable, whose popup simply says, 'The form data is contained within the variable $data. The form's original data is available as an array called $origData." I don't understand how to use this information... do I write $origData != $data; or what?

I'll even make you guys a deal... if you help me get this feature working, I'll write instructions for the wiki. Then, if you don't like it, you can 'compare_versions' and/or 'revert' the content using the 'history' tab, much like I'm trying to do with my form submissions.
 
P.S. - I still have /plugins/fabrik_form/fabrik2article, which I think is a vestigial feature of Fabrik 2.5 (since it is no longer on GitHub branch: joomla3). Should I remove this so that it doesn't interfere with /plugins/fabrik_form/article?
 
I don't think the article plugins are used very often (and Fabrik is a lot older than Joomla's version control).

If I got your very long text right you want a version control on Fabrik list entries.
You can add a form php plugin to manage a version number and copy the original data (to the same table or a log table).
$data and $origData are arrays (and I don't think they have exactly the same structure) so you have to loop and compare.

BTW: I think fabrik2article was in Fabrik2 (Joomla1.5) only.
 
Yes, I want version control in my fabrik list entries, but the article plugin is not recognizing that the article created on form submission is a new version of the same form when the same person goes back to their form, makes a change, and submits it.

Here's what I want:
1) User 1 -> Form 1 -> Article 1, Category 1
2) User 1 -> Form 2 -> Article 2, Category 2
3) User 2 -> Form 1 -> Article 3, Category 1
4) User 1 -> Form 1 -> Article 1, Caegory 1
5) Version Control between (1) and (4)

And here's what I'm getting:
1) User 1 -> Form 1 -> Article 1, Category 1
2) User 1 -> Form 2 -> Article 2, Category 2
3) User 2 -> Form 1 -> Article 3, Category 1
4) User 1 -> Form 1 -> Article 4, Category 1
5) Can't see which answers User 1 changed between submitting and modifying Form 1

... unless I hack the following resource locator: https://nuvacord.net/administrator/...b668573e70972ffc1211119ebcc=1&id1=548&id2=547, changing 'id1' and 'id2' to compare the different articles.

My only lead as to why this is not recognizing an edit is from /plugins/fabrik_form/article/article.php:133

$isNew = is_null($article) ? true : false;

Two things catch my attention with this line of code. First of all, I don't see where $article is defined (although I do see $version defined as 'new JVersion' on line 177), but I'm going to assume that this variable is being defined elsewhere, like in the required_once ... plugin-form.php, importPlugin('content'); in the $data array or something. I can't believe that it would be as simple as changing this to $articleId. The other thing that catches my attention about this line of code is that the table structure of my #__content shows that the Default for 'id' is 'None', not 'NULL'. A quick look at the next few lines demonstrates the importance:

Name Default
id None
asset_id 0
title
state NULL

So, upon re-examination do the coders still believe this code to be correct? If so, what else might I do to edit an existing article through a form submission for version control purposes?

Troester, I appreciate your comments and suggestions, but I don't know how to 'add a form php plugin to manage a version number and copy the original data (to the same table or a log table)'. More specifically, I do know how to add a form php plugin to this form, but I wouldn't know which PHP file (easy for me if you could reference an existing file) or code (hard for me to write) I would want to run. I also have no idea how to 'loop and compare' the $data and $origData variables.
 
I think i've fixed the bug in the article form plugin which was stopping it updating itself. From my brief tests I can see that editing a fabrik form record and saving it will update the version history in the Joomla article.
 
So, the article plugin still doesn't work. Can one of the Fabrik admins login to my site and figure out why? Warning: It's a little messy in there, but the most important form to apply this document control to is Registry - Client Registration: https://nuvacord.net/administrator/index.php?option=com_fabrik&view=form&layout=edit&id=279

If someone can cause this form to creat user-specific article versions, then I could apply those settings to the other forms.

Thanks.
 
It's working on my site:
editing the Fabrik record is adding a new version to the article.

Did you update from GitHub?
 
I did just update from GitHub earlier today.

When you got it working on your site, did you add the com_content fields required by the list_article plugin as a group or individually? For example, what is the Title of the article that you created and how did you define it?
 
Emm, until now it was all about FORM article plugin...
Setup:
  • a Fabrik list with elements you want to use to compose your article, at least you need
  • id (internal id)
  • title (to hold the title)
  • ref (element to hold the article id and category), best set to hidden + add/edit access = nobody
  • a template to create your article content (HTML/PHP/Joomla article)
  • the article FORM plugin, template selected, "Reference element" selecting your ref element, "Title" selecting your title element
    see the tooltips for matching the other elements
Now
  • when creating a new record it's creating a new J! article with the title and the content prepared in the template
  • when editing a record the existing article will be overridden with the title and the content prepared in the template,
    a J! article version is added
 
I just set up a test form/template/article as you described and it seems to have worked! My problem may have been with the Reference element... I was apparently using User ID as a reference. I will try to apply the fix to the important forms for version tracking, and I will let everybody know if it really works for me.

Thanks!
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    No members online now.
    Total: 143 (members: 1, guests: 142)
    Back
    Top