Nathan W replied 1 year ago

I would prefer an ongoing changelog.

Victor Font replied 1 year ago

Here's how I would design it. I would use a repeater field because of the flexibility it offers for field-level security and its suitability to serve as a workflow component in a complex, structured environment, such as you might find in a DEX Intranet project where approval chains are often variable.

A repeater is an embedded form. Each row in a repeater is an entry that belongs to that embedded form. On the front end, Formidable displays these entries like rows on a spreadsheet. while you don't say it directly in your post, when you say "the username of the person who edits the form", it suggests that at some point you may want to make things secure from changes if multiple people are accessing the same entry.

This may be especially true if you are designing a form used in a workflow environment. In a workflow, you may have a chain of people with different levels of change and/or approval authority. Unless you want anyone to change anyone else's prior entries, then you need to think about security.

Depending on the size or scalability of your project, you may find that you'll probably have to restrict field changes if you need to give authority to some to "look but don't change". Also, with a repeater you can capture multiple fields and include a "reason for change", for example. If that's a paragraph field, you'll have a memo explaining the change.

Getting the username is easy. You get it from the WordPress user object (https://developer.wordpress.org/reference/classes/wp_user/).

This requires you to write custom PHP code and fire it up it frm_setup_new_fields_vars and frm_setup_edit_fields_vars.

https://formidableforms.com/knowledgebase/frm_setup_new_fields_vars/
https://formidableforms.com/knowledgebase/frm_setup_edit_fields_vars/

By using these filters, you can prepopulate a row in the repeater with the user's name, WordPress id, and anything else you imagine you might need in an audit trail. You can make the name and id readonly on the front end and let the "reason for change" field be the only one the user can change. You could also make that field conditional and only allow an admin or the user that entered it to change the paragraph field.

Let us know how you make out, if you choose to follow these suggestions. If you need to talk to a developer to explore your ideas further, then please visit the Formidable Masterminds Developers Directory at https://formidable-masterminds.com/developers-directory/. I know you'll find someone that will love to help you out. This sounds like a fun project.