nodebb-community / nodebb-plugin-forms Goto Github PK

I have no clue what causes this.

Big list of things that need doing for initial release. Should make a separate issue for each that needs discussing.

Things already done:

• All different kinds of form elements
  • We have all standard and most advanced input types working as they should.
• Forms can be cloned and edited
• Captcha (including no-captcha)
• Easy-to-use, drag and drop creation interface
  • Works good, but a little too busy. Could use some tabs so that it's not so cluttered.

Needs doing:

• Private forms (only certain groups or users can see them)
• Option for the ability for users to edit their form response and see past forms
  • This is pretty crucial.
• Apply a group to a user
• Send an email to user(s) and/or group(s)
• Send a notification to user(s) and/or group(s)
• Send a pm on behalf of certain users to other users or groups
• Create a new topic
• Send email to a specific address
• Comment sections for submissions. (One public and one admin only)
• Analysis of form submissions (graphs, averages, etc.)

Would be nice, but not necessary for initial:

• Responsive forms (answers affect what is shown)
• Multiple stages (a user fills out one stage, another user fills out another stage) (maybe)
• Ability to add custom actions via an external api

The ability for users to edit their form response and see past forms should probably be the default. And have the option to dis-allow this.

Could have a page added to the users profile, reroute users that are not the user or an admin.

Need options for re-sending notifications when the submission is edited.

Actual display would be pretty easy, just render the form as normal with pre-filled fields, and alter submit functionality.

Something I find missing from even popular form software is detailed analysis tools. I think it could be a big selling point, especially for larger forums that want to use survey type forms.

Wouldn't need to be comprehensive for initial. But we should have a solid framework for viewing mass results, and a schema conducive to future tools.

Examples:
Choice Totals
Averages/Means/Medians
Results over time.
Submission time/location charts
Correlation between results.
Number of re-submissions/duplicates/comments/views/actions taken etc..

Related,
A submission schema that is easy to export to more comprehensive analysis software.

Multistage forms are done with the newForm action:

actions: {
  submitResponse: [
    { newForm: "accept-member" },
    { notify: [ 4, 10, 15 ] },
    { createTopic: "category" }
  ],
  editResponse: [
    { editForm: "accept-member" },
    { notify: [ 4, 10, 15 ] }
  ]
}

actions = {
  newForm: function (newFormId, submission){  /* create new form */ }
}

It does not work anymore?

So, there's a few ways we could go with this.

Apply a group immediately upon submission.
Have a simple yes/no resolution buttons for admins viewing the form submission.
Have multiple resolution buttons for admins viewing the form submission.
Have a drop down of groups available for admins viewing the form submission.

For initial release, in designer needs a 'resolutions' or 'actions' tab with submit, accept, and decline actions already added. The actions could have an editable list of groups that are applied or removed.

Ideas

Can assign a members field (array of uids) to form object, and 'Edit Members' tab on designer.

On the server, disallow any embedding, reroute uids that link to the form directly.

A Form actions panel/tab for covering these features:

Apply a group to a user
Send an email to user(s) and/or group(s)
Send a notification to user(s) and/or group(s)
Send a pm on behalf of certain users to other users or groups
Create a new topic
Send email to a specific address

Needs to be extensible while still easy to understand

Possible schema:

actions: {
  submitResponse: [
    { newForm: "accept-member" },
    { notify: [ 4, 10, 15 ] },
    { createTopic: "category" }
  ],
  editResponse: [
    { editForm: "accept-member" },
    { notify: [ 4, 10, 15 ] }
  ],
  acceptResponse: [
    { addGroups: ['vip'] }
  ]
}

On the server, the properties of each action would call a function or trigger a hook attached to each, that way we could easily add actions later, or even add external plugins. ex.

actions = {
  addGroup: function (groups, submission, form) { User.addGroups(submission.creator, groups); },
  sendEmails: function (emails, submission, form) { foreach(emails) { Email.sendToEmail(email); } },
  createTopic: function (category, submission, form) { Topics.create({ uid: submission.creator, title: form.title, content: submission.results }); },
  etc...
}

In the designer, we could read from that object to put a list of available actions.
Each property would also need a list of needed inputs too for entering in the designer.

Form Schema is what the designer saves and loads.

Currently stored and retrieved using Settings with some v3 helpers to translate the settings to the DOM.

Current testing schema

forms: [
  { formid: 'example',
    title: 'Visual Title',
    inputs: [ /* input objects */ ],
    method: 'submit', // Normally 'submit', which just stores the submission and runs actions, but can use http POST, GET, etc requests.
    action: '', // url for POST method etc..
    cmd: '', // Data object (paypal etc..)
    captchasite: '',
    container: '' // Bootstrap wrapper
  }
]

Other needed/possible properties:

users: [] // Array of uids that can see/submit this form. (besides admins).
groups: [] // Array of groups that can see/submit this form. (besides admins).
actions: [] // Array of action objects, see Form Actions issue.
expireAt: date // stop accepting new submissions after data.
allowComments: true // Allow comments on form submissions from users listed above.
allowReview: true // Let users to see the form submission/add comments.
allowEdit: true // Let users to edit previous form submissions.