Currently we have (to the best of my knowledge)...

            <form-builder
              fbms-base-url="/fbms/api/v1/forms/"
              fbms-form-name="communication-preferences"
              response-url="/fbms/api/v1/responses/"
              oidc-url="/uPortal/api/v5-1/userinfo">
            </form-builder>

Better would be (as far as I can see)...

            <form-builder
              fbms-base-url="/fbms"
              fbms-form-fname="communication-preferences"
              oidc-url="/uPortal/api/v5-1/userinfo">
            </form-builder>

Differences:

• fbms-base-url does not include the /api/v1/forms/ path info (which can be hard-coded)
• fbms-form-name has been renamed to fbms-form-fname
• response-url is not required (b/c it can be infered from fbms-base-url just as easily as the /forms/ endpoint)

Also Note

The URI for users' previous responses is /fbms/api/v1/submissions, not /fbms/api/v1/responses.

It doesn't prevent the data from reaching the server, and persisting, but it prevents user feedback on the page.

The build produces...

• build/static/js/form-builder.js
• build/static/js/main.5f6c9cfc.js.map
  I don't believe the browser can use the .map file unless it matches in name.

The form-builder UI is now correctly displaying server-side validation errors.

But I notice now that if I produce a validation error and then correct it, the error still displays (in red) when I re-submit the form. The submission is a success, and the updated/corrected version is saved, but the user is told that the validation issue is still a problem.

Description

Affects Version

1.1.0

Currently the project builds to a file with a name like main.e3b45x7.js.

I understand the reasons for this practice, but it plays havoc with...

• The build system that may need to copy this file
• The portlet-definition.xml that needs to reference this file in (static) HTML

Please build to form-builder.js or somesuch.

uPortal contrib is a common space for uPortal web components and microservices to be shared with the Apereo community.
Repositories can be added through an intake process.
uPortal form build has gone through the intake process and been approved.
https://groups.google.com/a/apereo.org/d/msg/uportal-dev/P2f3srF8Gxk/o3rExWAZAgAJ

There are a few options for how this repo could be shared with uPortal contrib.

1. Repo is transferred to uPortal contrib
2. Repo is forked to uPortal contrib
3. Repo is mirrored to uPortal contrib

Usually option 1 is preferred because it preserves the issue tracker through the migration.
Thoughts on next steps @cparaiso ?

Description

Affects Version

1.1.0

https://help.github.com/articles/about-topics/
https://help.github.com/articles/classifying-your-repository-with-topics/

Topics help repository become more discoverable.
Some topics that could be a good fit web-component, react, uportal, and form-builder.

I'm currently getting "There was a problem finding your form."

I do expect to provide some default responses for SCCCD, but the component needs to support and empty response (404) for the user's previous submission.

I'd say this one is a priority.

For Form Forwarding, I suspect we need something like...

<form-builder [oidc-url="/uPortal/api/v5-1/userinfo"] [fbms-url-base="/fbms"] fbms-form-fname="abc123" />

I regret to report the Form-Forwarding feature appears no longer to work...

The screen capture shows how the X-FBMS-FormForward HTTP header is being sent with the response, but the form in the page has not changed.

I just ran the build. It appears to produce separate .js and .css files.

@cparaiso @ChristianMurphy

History in PR #68

react-jsonschema-form should be unpinned relatively soon. This will cause at least App.js:transformErrors to fail and should be fixed.

Name: X-FBMS-FormForward

You will only ever get one of these headers on a successful submission.

Example value: abc123

After upgrading from 1.2.1 to 1.3.0, IE / Edge crashes. Not clear which commit(s) between the versions are at fault.

Suggestion: use Bootstrap and a Font Awesome icon.

A lot of people are going to mess up integration with the required REST endpoints the firsts time, which include...

• The uPortal /userinfo endpoint
• The FBMS /forms endpoint
• The FBMS /submissions endpoint

We should...

• Provide adequate coverage of this step in the README
• Provide a user-friendly message in the UI if it doesn't work

Submission errors should show a list of messages to user sent from the back end as well as render form.

This part appears to be missing at present.

The committers for this project are those for uPortal itself, documented as of this writing in COMMITTERS.md in Jasig/uPortal.

https://github.com/uPortal-contrib/form-builder/blob/master/COMMITTERS.md

Currently access is limited to only @cparaiso and @uPortal-contrib/uportal-steering-committee

I would expect that when the form displays server-side submission errors (e.g. validation issues) the widgets on the form would remain exactly as the user just set them.

Instead, the form is reverting to the state it had when the page first loaded.