Make auto-generated admin area for all collections

[SachaG]

By looping over collections, shouldn't be too hard. Also generate routes, etc.

[Julien-Sytadelle]

Hi,

That's what lbke/vulcan-backoffice-builder from Eric Burel does well. It uses material-ui but adaptation to Boostrap should not be hard.

[eric-burel]

Yep it already works, and I did my best to allow customization, you can check Awesome Vulcan code.

If you want to integrate a backoffice to the core, I'd advise to add vulcan:menu to the core too, it helps managing menu entries that are either autogenerated or spread among multiple package (eg if you want to enhance the admin interface with additional debug pages). What lacks is just a generic MenuItem component. For the moment I expect the user to implement the menu, so I just wrote a MUI version that cannot be customized.

Also I overcomplicated the UI a bit in my backoffice implementation (I did not want modal), a simple DataTable should actually be enough as it provides all what you need (search, add/edit buttons, and paginated data). Thus no problem with bootstrap or material-ui as it could work out of the box.

Eventually my component naming is bad, it can lead to clashes, it simply needs some prefixing.

With those tweaks and a few improvements you should already have a working version. I'd be glad to contribute, having a solid autogenerated backoffice is really an awesome feature.

[SachaG]

Oh wow, I can't even keep up with all the things you make! :)

Do you think that package should be merged into core? On one hand maybe no, because it's better to keep the core lightweight to make it easier to find code, understand how things works, etc.; on the other hand if things are not in core it's easy to miss them (for example I didn't know about that package myself…). And having everything in the same repo also makes it easier to maintain the code (no need to browse to different repos, run git push 10 times, etc.).

Or maybe the answer is to keep it out of core, but do a better job of suggesting useful packages, for example as the last step of the getting-started tutorial? That's a pretty easy step to take at least.

[eric-burel]

Yeah actually that's mostly what I've been working on this last year regarding Vulcan, because thanks to this I got something to show to my client almost at day 1 of development, and they can start playing around with forms. For professional apps the backoffice itself is enough, so basically I write the schema, custom form inputs, and I'm done (well, in theory ^^)

I think it makes sense to add such an admin panel in the core, as some high-level frameworks do it too. I think about Django for example, it includes an admin panel that does exactly this, with customizable forms. And this is really a love feature. It's a good way to onboard and convince non-developers too. The solid backoffice of WordPress (+ it's theming ecosystem) is the number 1 reason it's still around in my opinion. Eventually, Mongo does not provide any free UI tools (that's also true for many NoSQL db sadly) to explore the DB content, so adding this at the app/framework level is appreciated.

That would mean:

• adding vulcan:menu to the core. It make sense anyway since we handle routing in the core. This would make this backoffice easily extendable by adding additionnal menu items to it. https://github.com/lbke/vulcan-menu
• writing a vulcan:backoffice package. It could be a simplified version of backoffice-builder relying on Bootstrap. It would loop over collections, create an admin page for each (simply a DataTable), create the route, and add a menu item. https://github.com/lbke/vulcan-backoffice-builder
• adding Users collection is a bit trickier right now (you can't create them as any other item because of the password) but I managed to figure a working implementation https://github.com/lbke/vulcan-users-manager

We could also:

• merge this with vulcan:admin
• maybe plug vulcan:debug to it (so that when debug is enabled, it adds a menu item to this page)?

@Apollinaire just opened a PR that provides layout for vulcan:admin: https://github.com/VulcanJS/Vulcan/pull/2177

Of course I can take care of this, I just need some time since apollo 2 is still the big priority.

Concerning listing packages I created a page on Awesome Vulcan: https://www.awesome-vulcan.com/packages There is also this list on github: https://github.com/amandeepmittal/awesome-vulcan My articles are on it already so I guess it's pretty well maintained lol

With a bit of additional work I could finalize this app and plug the Github repo to it too so both are sync.

[SachaG]

Sounds good, let's merge it into vulcan:admin then. And we can add vulcan:menu too, although I don't know if that feature is as necessary (adding a new <Link> to your menu component is not that much work).

Let's focus on finishing up with the Apollo2 stuff first (and maybe migrating to a better accounts system, too) and this can come after as a "nice-to-have" feature :)

[Julien-Sytadelle]

That's great ! Coming from Django, the backoffice builder is what convinced me to have a try at Vulcan.

[Apollinaire]

About vulcan:menu : I've written almost the same script as Eric's for my app. It's powerful because it lets you leverage the package system, without dependencies. Every package could add its own link in the menu and it would mean even better plugin system. IMO if a package defines a route it should also define an entry to the menu so we can get a Link automatically directly in the UI. So i'm totally wheighing in for this :+1:

[macrozone]

awesome! I used a self-made admin solution back for our meteor-mantra apps (https://github.com/panter/manul-admin), which was built on top of uniforms and react-griddle and i am now considering vulcan for a backoffice/admin-app, so i am looking forward to try out the backoffice-builder! Maybe i can also help contributing and share my experiences

[eric-burel]

Hi, I've just pushed a feature/backoffice branch on this repo + the Starter repo. It's just a draft but you can already get a grasp of the code.

There are 3 packages: vulcan:menu, vulcan:backoffice and vulcan:backoffice-users (this is a special case because out-of-the-box you can't create user through the smart form, they would lack a password).

I expect the user to explicitly setup the backoffice right now. I think we could change this, by writing a registerBackofficeSettings function (to allow customization) and generating the backoffice inside a Meteor.startup callback for a better experience.

I did not manage to loop over collections though, I get Meteor provides some value for this like Meteor.Collections or smth?

Edit: oh also there is no actual UI yet, just 2 divs, don't be disappointed if you test this already ^^

[SachaG]

Great! I don't know if I like the term "backoffice" though, I think "admin" or "dashboard" would be clearer. Just a personal preference.

And yeah it'd be great to have it more or less auto-generated ultimately. I think if it needs customization, I would rather encourage people to do so using the "normal" Vulcan APIs like replaceComponent, etc. instead of adding another API layer?

[eric-burel]

I think I get it. That would mean refactoring a bit my solution to transform createListComponent into a wrapper React component for example. So that if you want to change the config for a collection (eg authorized groups), you simply replace this "wrapper" component so it passes different props to the actual component. This way you can tweak the settings by simply using replaceComponent. I'll try that.

Edit: actually I guess it's a job for callbacks, we could have a vulcan:backoffice.setup callback that allow to return a custom config for the backoffice.

[Apollinaire]

Maybe the vulcan:menu should be part of vulcan:lib since it's just one script exporting the object, a getter and a setter?

[eric-burel]

Hi, just trying to sum up what's necessary to finish this feature, as asked by @Julien-Sytadelle. The branch is feature/backoffice :

• Update the branch tot he latester devel because we have a lot of updates on Material UI
• Create a LeftMenuLayout for Bootstrap and Material UI. Note that Material UI already provides an example.
• Load the menu items from vulcan:menu in this layout
• Move vulcan:menu into the vulcan:lib to clean things up as suggested by Apollinaire done
• Create a callback that allow to configure the backoffice by modifying the default settings
• Call that "Admin dashboard" instead of Backoffice to be clearer and more consistent with traditionnal CMS
• Add a call to Meteor.startup that trigger the admin dashboard generation Done
• Maybe cleanup the code as suggested earlier, to make the generated components replaceable. Eg  createListComponent could simply be a React component instead of a function that create a component. It would gives us more flexibility.

This list may be incomplete as currently this feature has been a bit behind in my to do list.

[Julien-Sytadelle]

Thanks Eric. I did a merge from devel this morning and until now it seems fine.

Le 1 juil. 2019 à 15:25, à 15:25, Eric Burel notifications@github.com a écrit:

Hi, just trying to sum up what's necessary to finish this feature, as asked by @Julien-Sytadelle. The branch is feature/backoffice :

• Update the branch tot he latester devel because we have a lot of updates on Material UI
• Create a LeftMenuLayout for Bootstrap and Material UI. Note that Material UI already provides an example.
• Load the menu items from vulcan:menu in this layout
• Move vulcan:menu into the vulcan:lib to clean things up as suggested by Apollinaire
• Create a callback that allow to configure the backoffice by modifying the default settings
• Call that "Admin dashboard" instead of Backoffice to be clearer and more consistent with traditionnal CMS
• Add a call to Meteor.startup that trigger the admin dashboard generation
• Maybe cleanup the code as suggested earlier, to make the generated components replaceable. Eg  createListComponent could simply be a React component instead of a function that create a component. It would gives us more flexbility

This list may be incomplete as currently this feature has been a bit behind in my to do list.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/VulcanJS/Vulcan/issues/2176#issuecomment-507263117

[eric-burel]

It's up to date on "feature/backoffice", to test you can add "vulcan:backoffice" to ".meteor/packages", it will automatically add a backoffice on "/backoffice".

It's not configurable at all yet (see Awesome Vulcan for a more complex example meant for production) but that's a working proof of concept. You can enable/disable it through the "backoffice.enabled" setting, it's enabled as a default in Dev mode and disabled in production for the moment. Only the admin can have full features.

Next step is a better UI, now we have storybook we could create a LeftMenuLayout, and more configuration

[eric-burel]

I am worried about something, I did not seem to be able to add routes after startup.

I need backoffice creation to be there: 1 - Fill the Collection object 2 - Create the backoffice routes

To be sure we have all collections, the basic idea is to call the backoffice creation after we loaded very collection, so in a Meteor.startup. But it in turns will call addRoute , which does not work in a startup. This is because it means Routes are created after the document is loaded, so they don't exist when you try to open an URL.

I've removed the meteor.startup, but then it means that I am not sure I have all collections in my Collections object, especially the collections coming from other packages.

Basically I would need some way to run the backoffice creation after all the createCollection are called but before startup or smth like that.

[eric-burel]

We need this to be implemented first: https://github.com/VulcanJS/Vulcan/issues/2404 Otherwise we can't call addRoute in Meteor.startup. Hopefully this is an easy issue I should implement it quickly.

[eric-burel]

Ok I get a working draft. Routes, menu items and components are correctly generated

To recap the last steps before merge:

• create a generic LeftMenuLayout to have a clean display of available collections on Bootstrap and MUI
• allow to access a detailed view for each item. The route exists but is not linked in the Datatable. We would probably need a small option to add columns in a datatable in addition to the default ones (right now we can only hard replace them which is tedious)
• add a minimal permission handling. The home of the backoffice should have a login form and routes should be protected. We could limit access to the "admin" role for this first implementation.

Non necessary for merging but todo for a final version:

• make the backoffice configurable. It could simply be a callback that is run to generate the options, like: backofficeOptions = runCallback('backoffice.options', { iterator: defaultOptions}).
• actually defines the available options, enhance them where appliable. Those options are mostly permissions, see https://github.com/VulcanJS/Vulcan/issues/2390 for the future syntax

[eric-burel]

The backoffice should probably display basic infos about Collection callbacks to the admin (mostly the number of registered callbacks). https://docs.vulcanjs.org/callbacks.html

[yannick-mayeur]

Do you know if there is an easy way of knowing the number of rows in a collection?

[eric-burel]

Cliend side you should have a totalCount alongside the data when using a multi

[eric-burel]

Beware of this issue though: https://github.com/VulcanJS/Vulcan/issues/2066 It dates from before the filter update but basically you can't apply users custom permissions when counting rows There is no solution so just keep in mind that totalCount maube sometimes higher than the actual number of available documents. That's what can make pagination tricky for example

[eric-burel]

A first version will be included in next release :tada: Big thanks to @loustak and @yannick-mayeur

You can test by adding meteor add vulcan:backoffice in any app. Backoffice is only available to the admin right now but in the future we could add more options.