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

Attach Fields - Also for Create #3242

Open
rctneil opened this issue Sep 12, 2024 · 5 comments
Open

Attach Fields - Also for Create #3242

rctneil opened this issue Sep 12, 2024 · 5 comments
Labels

Comments

@rctneil
Copy link
Contributor

rctneil commented Sep 12, 2024

In regards to the attach_fields option.

If the Record you wish to attach does not actually exist and you have to create it by clicking the "Create xxx" button, the attach_fields should be available somehow in this workflow too.

This would ensure that both the Attach and Create options work the same way and can end with a consistent result.

Workaround:

  1. Create new item.
  2. Detach item from record.
  3. Re-attach and complete the attach fields in the popup.
@Paul-Bob
Copy link
Contributor

Hello @rctneil.

I get the use-case and it can be custom-implemented already.

1 - Define the fields from atach_fields on that resource you are creating, you can even make a visible block considering the presence of a parent resource/record and make them visible only when created from a specific association.
2 - Using create_success_action and params to fill the join record on the avo controller.

def create_success_action
  @record.join_record.update!(some_attribute: params[...][:some_attribute])

  super
end

How do you think this feature should be integrated into Avo? We should consider that not all use cases may want this behavior, maybe some people want it only on attach.

@rctneil
Copy link
Contributor Author

rctneil commented Sep 13, 2024

Ok, I'll try custom-implementing this.

I do still see this as a feature that Avo should offer. To accomodate more users, may an opt in approach would be useful?

Eg, keep the custom functionality as it is but provide an on_creation: true option on attach_fields?

Maybe it's not suitable for integration, but thought I would suggest it anyway as more ideas are always good i guess.

@Paul-Bob
Copy link
Contributor

Maybe a new option: create_fields

def the_fields
  -> {
    field ...
  }
end

def fields
  field ...,
    attach_fields: the_fields,
    create_fields: the_fields,
end

Whatever the DSL is we would render them in a static position on the page probably at the end of the page, then if you want the fields on a panel or in a sidebar, or even in a tab you will still fall back to a custom implementation. IMHO if the custom implementation is straightforward and not that time-consuming is worth documenting a recipe instead of implementing a native feature that limits the posibilities.

but thought I would suggest it anyway as more ideas are always good i guess.

For sure! New ideas and feedback are always welcomed, thank you for that!

Ok, I'll try custom-implementing this.

Let me know how it goes, and if you find any obstacles, maybe we could create a recipe and document it because the workaround isn't pleasant.

@rctneil
Copy link
Contributor Author

rctneil commented Sep 13, 2024

Ok, Yes, I'll try to test it out this weekend and will report back.

The create_fields idea is actually much nicer, as it's clear where those fields will be used. Yes, bottom of the page sounds fine to me as a default.

Copy link
Contributor

This issue has been marked as stale because there was no activity for the past 15 days.

@github-actions github-actions bot added the Stale label Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

2 participants