View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5599 | Composr | core | public | 2024-02-08 16:56 | 2025-01-05 00:57 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 10.0.46 | ||||
| Fixed in Version | 10.0.47 | ||||
| Summary | 5599: Add form_handlers hooks functionality | ||||
| Description | Make new hooks->systems->form_handlers in Composr v10 to handle forms submitted (such as sending form data to external software systems). A hook can be created within form_handlers to handle forms submitted. Available methods (for now) include handle_catalogue_entry, handle_registration, handle_profile_edit. Document use. Port to v11. | ||||
| Additional Information | Normally, as v10 is in maintenance status, I would not accept / implement new features. However, this is for a client. | ||||
| Tags | Roadmap: Over the horizon, Roadmap: v11 partial implementation | ||||
| Attach Tags | |||||
| Attached Files | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
I'm not really following this. Are you saying you want every page view to listen for if a POST form is submitted and handle it as per hooks? Why not just make a new entry-point script and direct a form to that directly, just like form_to_email.php does for relaying emails? |
|
|
No that's not the intention; that would be overkill to run it every time there is POST data. The intention is only certain things would utilize the hooks. For instance, submitting a catalogue entry would call handle_catalogue_entry. Registering a user account would call handle_registration. And editing your profile would call handle_profile_edit. The idea is that, for example, if someone has third-party CRM software, data from key areas of Composr (catalogues, user registration, and profiles) can be relayed via these hooks to the software. This is not for custom forms (which do not go through the catalogues system). It could also be used to call webhooks, save / sync data elsewhere, etc. |
|
|
That makes much more sense. In which case, why not have a different set of hooks for each source (catalogue entries etc). Is there a reason it is being brought together in one set of hooks? Seems like an unnecessary forcing of disparate systems together. |
|
|
There is no reason for keeping it together. In that case, they can be separated out as you suggested (and I agree it is probably better that way). |
|
|
Automated response: Form handler support This hotfix adds basic form handler support for joining and for editing profiles. Catalogue handling has not yet been implemented. By default, this does nothing; developers should write their own form handler hooks. Documentation will be provided later (and so will catalogue support). |
|
|
Fixed in git commit e2c0560a90 (https://gitlab.com/composr-foundation/composr/commit/e2c0560a90 - link will become active once code pushed to GitLab) A hotfix (a TAR of files to upload) has been uploaded to this issue. These files are made to the latest intra-version state (i.e. may roll in earlier fixes too if made to the same files) - so only upload files newer than what you have already. If there are files in a hot-fix that you don't have then they probably relate to addons that you don't have installed and should be skipped. Always take backups of files you are replacing or keep a copy of the manual installer for your version, and only apply fixes you need. These hotfixes are not necessarily reliable or well supported. Not sure how to extract TAR files to your Windows computer? Try 7-zip (http://www.7-zip.org/). |
|
|
Patrick, this can be marked done? |
|
|
I'm going to mark it partial implementation. The original issue also specified catalogue form handlers, which has not yet been implemented. |
|
|
Okay I was wrong; I already did implement form handlers for catalogue entries in v11. I'm not sure why I missed that. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-02-08 16:56 | PDStig | New Issue | |
| 2024-02-08 16:56 | PDStig | Status | Not Assigned => Assigned |
| 2024-02-08 16:56 | PDStig | Assigned To | => user4172 |
| 2024-02-08 16:58 | PDStig | Description Updated | |
| 2024-02-08 16:58 | PDStig | Description Updated | |
| 2024-02-10 19:39 | Chris Graham | Note Added: 0008304 | |
| 2024-02-10 19:45 | PDStig | Note Added: 0008305 | |
| 2024-02-10 19:48 | PDStig | Note Edited: 0008305 | |
| 2024-02-10 19:58 | Chris Graham | Note Added: 0008312 | |
| 2024-02-10 20:25 | PDStig | Note Added: 0008316 | |
| 2024-08-04 21:53 | Chris Graham | Note Added: 0009081 | |
| 2024-08-04 21:54 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2024-08-04 22:44 | PDStig | Note Added: 0009092 | |
| 2024-08-04 22:44 | PDStig | Tag Detached: Roadmap: v11 | |
| 2024-08-04 22:44 | PDStig | Tag Attached: Roadmap: v11 partial implementation | |
| 2024-08-04 22:44 | PDStig | Tag Attached: Roadmap: Over the horizon | |
| 2025-01-05 00:57 | PDStig | Status | Assigned => Resolved |
| 2025-01-05 00:57 | PDStig | Resolution | open => fixed |
| 2025-01-05 00:57 | PDStig | Note Added: 0009769 |
