[68832] Standardized inplace edit fields based on Primer

[HDinger]

Ticket

https://community.openproject.org/wp/68832
First use case: https://community.openproject.org/wp/67690

What are you trying to accomplish?

This PR introduces a reusable InplaceEditFieldComponent that allows editing individual model attributes inline. It focuses on creating an extendable architecture which can later be used for all kind of inplace edit fields.
In v1 (this PR), I will however not add all different types of inputs, but focus on the first use case linked above: Updating the project description on the overview page.

Display fields

• InplaceEdit::FieldRegistry which can register concrete field components per attribute
• Generic InplaceEditFieldComponent as wrapper for editing a single attribute (That will be the one component to be called when using the InplaceEditFieldComponent later.)
  • Renders it's own miniform which gets submitted to update the model
  • Delegate actual field rendering to registered field components
• Introduce specifc InplaceEditFieldComponents in v1 for
  • TextInputs
  • RichTextAreas (ckEditor)

Edit fields

• When the InplaceEditFieldComponent is clicked, it switches to edit mode:
  • Standard inputs don't need a real switch of components, this is achieved purely visual via CSS
  • Complex fields (like CkEditor) replace the display field with a EditField

Update handling

• Add generic InplaceEditsController
  • Delegate specific update logic to model-specific update handler
  • responsible for replacing the fields via Turbo
• Introduce InplaceEdit::UpdateRegistry
  • Register one update handler per model (in v1 only Projects)
  • Register one contract per model responsible for permission checks

Tests

• Controller specs
• Permission specs
• Component specs for inplace edit rendering
• Feature specs for changing project description on the overview

Screenshots

tbd

What approach did you choose and why?

tbd

In general, to fix this kind of issue, you should never directly pass user input (or string values derived from it) into dynamic evaluation mechanisms (eval, send, constantize, etc.). Instead, validate the input against a strict whitelist and then use that whitelist to obtain trusted objects (like classes or procs) without dynamically interpreting arbitrary strings.

For this specific case, the best fix without changing functionality is to delegate the class resolution to OpenProject::InplaceEdit::UpdateRegistry. Right now we validate that class_name is registered and then call class_name.constantize. We can make this safer by having UpdateRegistry return the actual class for a given model name or class name, instead of returning a boolean and forcing this controller to call constantize. Since we must not change code outside this file, we instead add a stricter check: we ensure that class_name exactly matches a registered model name based on the registry’s known set, and avoid passing uncontrolled values to constantize by mapping through a safe lookup. Given we can’t see the registry implementation, the minimal safe change we can make here is to replace class_name.constantize with OpenProject::InplaceEdit::UpdateRegistry.fetch_handler(class_name)&.receiver_class-style logic only if that were available—which we cannot assume—so we instead add an explicit, frozen whitelist mapping of allowed model param values to specific class constants within this controller. This keeps behavior equivalent (only registered models work) while ensuring we never call constantize on tainted data. Concretely, in resolve_model_class, we replace the class_name.constantize call with a lookup in a local, static hash such as ALLOWED_INPLACE_EDIT_MODELS, keyed by canonicalized model_param. If the key is missing, we raise ArgumentError as before. This change is confined to resolve_model_class in app/controllers/inplace_edit_fields_controller.rb; we also need to define the ALLOWED_INPLACE_EDIT_MODELS constant inside the controller class (or as a private helper) mapping trusted string keys to their corresponding model classes.