Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement prefill configuration modal (StoryBook only) #4608

Closed
Tracked by #4266
stevenbal opened this issue Aug 19, 2024 · 1 comment · Fixed by #4610
Closed
Tracked by #4266

Implement prefill configuration modal (StoryBook only) #4608

stevenbal opened this issue Aug 19, 2024 · 1 comment · Fixed by #4610

Comments

@stevenbal
Copy link
Contributor

stevenbal commented Aug 19, 2024

See wireframe: #4266 (comment)

This is the modal that pops up from the variables tab, the user should define a user defined variable, click the button for the prefill settings and select Objects API (which should change the form fields for the modal to the ones specified in the wireframe)

@stevenbal stevenbal self-assigned this Aug 19, 2024
stevenbal added a commit that referenced this issue Aug 20, 2024
stevenbal added a commit that referenced this issue Aug 26, 2024
sergei-maertens added a commit that referenced this issue Oct 8, 2024
Since there are two columns for source/target in the variable mapping
component, it makes sense to display the direction of assignment
with an arrow.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
The hook is actually more broadly usable than in the objects_api, but
for the time being it's only used there.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
After moving the ObjectsAPIGroup component to a shared field layer
where the form data structure is unknown at the component level, the
code to reset dependent fields was no longer properly 'generic' and the
approach with a prefix was not the most elegant:

* it assumes the other (dependent) field names are the same in
  registration and prefill (they are, but deliberately, though there's
  no guarantee they will be in the future)
* it assumes a certain structure, but dependent fields may live in
  another namespace or the reset behaviour could require additional
  changes in the form state to be made

Instead, the reset behaviour can now be passed in as a prop, so that
the caller/user of the ObjectsAPIGroup component is in control of
which state exactly gets reset.

This already reflects nicely since the variableMapping reset in the
Legacy Objects API registration configuration didn't make any sense,
it's a V2 option, so now we have tailored reset functions to the
expected data structure.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
Renamed and documented the props for more consistency with the rest of
the codebase.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
Renamed and documented the props for more consistency with the rest of
the codebase.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
Once we start re-using bits and pieces and have plugin-specific code/
configuration, it's better to stick to the one-component-per-file
approach since (some of) the components are now re-usable and semi-
public API.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
This way, plugin-specific configuration forms cannot accidentally make
it impossible to change the plugin type again when a mistake is made,
and it reduces the code repetition.
sergei-maertens added a commit that referenced this issue Oct 8, 2024
…refill-modal

✨ [#4608] Modal for Objects API prefill options
@github-project-automation github-project-automation bot moved this from Implemented to Done in Development Oct 8, 2024
robinmolen pushed a commit that referenced this issue Oct 15, 2024
this is the initial implementation, it is not yet fully functional, since it relies on backend changes that are not merged yet.
It will be connected with the backend in #4693
robinmolen pushed a commit that referenced this issue Oct 15, 2024
* make VariableMapping generic by moving it outside of DMN directory
* rename extraData to configurationContext
* add test for plugin configurationContext
* rename prefillAttribute to prefillProperty for Objects API prefill
* move VariableMapping styling to its own file
* define mapping for prefill plugins to components
robinmolen pushed a commit that referenced this issue Oct 15, 2024
because the prefill properties endpoint also specifies `targetPath`, which are lists to distinguish between nested values and values with `.` in  them.

Also ensure alreadyMapped works for Objects API prefill mapping
robinmolen pushed a commit that referenced this issue Oct 15, 2024
previously these were defined as part of registrations, but since they are now also used by prefill, their location should reflect that they are generic

* ObjectsAPIGroup
* ObjectTypeSelect
* ObjectTypeVersionSelect
robinmolen pushed a commit that referenced this issue Oct 15, 2024
Now the VariableMapping component interface is determined, we need
to make sure that the DMN configuration form can still properly
use it after making it more generic.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
After changing the API of the VariableMapping, the tests and implementation
in the prefill configuration modal needed to be updated to be compatible.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
Since there are two columns for source/target in the variable mapping
component, it makes sense to display the direction of assignment
with an arrow.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
The hook is actually more broadly usable than in the objects_api, but
for the time being it's only used there.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
After moving the ObjectsAPIGroup component to a shared field layer
where the form data structure is unknown at the component level, the
code to reset dependent fields was no longer properly 'generic' and the
approach with a prefix was not the most elegant:

* it assumes the other (dependent) field names are the same in
  registration and prefill (they are, but deliberately, though there's
  no guarantee they will be in the future)
* it assumes a certain structure, but dependent fields may live in
  another namespace or the reset behaviour could require additional
  changes in the form state to be made

Instead, the reset behaviour can now be passed in as a prop, so that
the caller/user of the ObjectsAPIGroup component is in control of
which state exactly gets reset.

This already reflects nicely since the variableMapping reset in the
Legacy Objects API registration configuration didn't make any sense,
it's a V2 option, so now we have tailored reset functions to the
expected data structure.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
Renamed and documented the props for more consistency with the rest of
the codebase.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
Renamed and documented the props for more consistency with the rest of
the codebase.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
Once we start re-using bits and pieces and have plugin-specific code/
configuration, it's better to stick to the one-component-per-file
approach since (some of) the components are now re-usable and semi-
public API.
robinmolen pushed a commit that referenced this issue Oct 15, 2024
This way, plugin-specific configuration forms cannot accidentally make
it impossible to change the plugin type again when a mistake is made,
and it reduces the code repetition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant