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

Multiple BREAD for single table/model #5826

Open
cyyeoh opened this issue Dec 14, 2023 · 1 comment
Open

Multiple BREAD for single table/model #5826

cyyeoh opened this issue Dec 14, 2023 · 1 comment
Labels

Comments

@cyyeoh
Copy link

cyyeoh commented Dec 14, 2023

Laravel version

No response

PHP version

No response

Voyager version

No response

Description of problem

Is it possible for me to create multiple BREADs for one singular table?
Example:
One table named Customer
One BREAD where only shows Customer that is living in one state with use of scope
One BREAD where shows Customer that is living in another state with use of scope
One BREAD where shows Customer that is living in another different state with use of scope
The BREADs are created so admin can select on menu item where which state they want to view, such as choosing StateA on sidebar will lead to page where only shows StateA customers, StateB shows StateB customers and so on....

Or is there any other way to do this?

Proposed solution

Allow one database table/model to have multiple BREAD

Alternatives considered

No response

Additional context

No response

@cyyeoh cyyeoh added the feature label Dec 14, 2023
@Emerica
Copy link
Contributor

Emerica commented Dec 14, 2023

Depends on your needs of course.

You can "fake" that with search filters.
Just make new menu items with different search keys
admin/customers?key=state&filter=contains&s=stateA
admin/customers?key=state&filter=contains&s=stateB

You might even be able to add mass action buttons instead of menu's, maintaining one "customers" menu with mass action shortcuts at the top. Create action buttons, with something like, probably better to use route keys, but for example.
https://voyager-docs.devdojo.com/customization/action-buttons

public function getDefaultRoute()
    {
      return URL::to('admin/customers?key=state&filter=contains&s=stateA');
    }
    
    public function massAction($ids, $comingFrom)
    {
      return redirect($this->getDefaultRoute());
    }
    

You can make a mass action for each of your "filters"
It's using the same BREAD but maybe that impacts your end goals as it makes use of the search, which you want to use for something else.


You can override the BREAD resources for that table and just build your own interface or lightly modify the existing one.
Make a /resources/vendor/voyager/[model]/ folder , so /resources/vendor/voyager/customers/
Copy the /vendor/tcg/voyager/resources/views/bread/edit-add.blade.php to /resources/vendor/voyager/customers/edit-add.blade.php
or
Copy the /vendor/tcg/voyager/resources/views/bread/browse.php to /resources/vendor/voyager/customers/browse.blade.php

^ make your changes to that blade, point it at your own controller and do whatever you want.


A hacky partial result would require you to remove the UNIQUE constraint on data_types.name, and then probably deal with other complications, like the listing not showing up in the bread list.
This prevents you from having two BREAD data rows with the same table name.

You could potentially make models for each of the situations you need, but have them all point at the same database table.
App\Models\customersStateA App\Models\customersStateB for example, and within each model you could
protected $table = 'customers';
Sadly, Voyagers bread editor isn't being smart enough to use the defined models table, instead of the table name it has in the form. It does hint about wanting to on the Model tooltip though...
You can remove the readonly part of the tablename field in the bread with the object inspector, or database editor, rename an existing bread and then create a new one for the existing table, but the renamed one's still going to be looking for a non-existing table when you goto browse or use it. Might as well just make your own livewire component at that point for all the trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants