I'm looking for suggestions for the best approach to create an application process that results in members being added to a committee. The entire process should be manageable through committee managers not a central site admin/manager. I definitely want to do this "the Volto way".
What I have now:
A committee content type which can have committee managers, currently the managers can add content to the committee.
What I want next:
It should be possible for ordinary site members to request membership and a committee manager
would then be able to authorize membership, making the requester into a committee member. Once authorized, the committee member would be able to contribute content to the commitee.
I'm not looking for anything like a detailed step by step, more like the right mechanisms that might be peculiar to Volto. It could be that the "content-type-centric" approach is totally wrong and I should be thinking in a different way, I'm open to adjusting my approach also.
This sounds similar to the sort of thing that is handled by collective.workspace, but it needs to be updated to support modern Plone versions and Volto.
I think the core of collective.workspace would still be useful for keeping track of members of a committee in different states, and connecting those states to Plone groups with local roles.
It needs first REST API services to get and update the workspace members, and then a volto frontend could be built using those endpoints.
Given a sound underlying architecture through collective.workspace, the REST API stuff sounds very doable. I'll work with a react dev for the Volto side of things.
@davisagli thanks... will try this route over the next couple weeks.
@pigeonflight We solved this problem previously in a different way to collective.workspace. Having a tight coupling between a group and a content object is not always what you want.
It lets you have a custom form and workflow for adding new users, approving them and assigning them to groups. And you can have rules on which groups get to approve which users and what options in the form result in adding to which group. We use this for hundreds of groups on one site.
I can't remember if it worked for existing members but wouldn't be hard to make it do that.
The nice thing about this solution is that it will work for any groups and then you can do what you want with these groups. Also the forms can be very custom and collect different information that you can also send elsewhere via other action adapters.
Compared to the built in plone registration system with custom schemas you get a lot more flexibility.
But, it's not volto. We upgraded it to easyform I think but we didn't upgrade it to volto-form-block. No one has updated easyform to volto which is a real shame since it had a lot more features. And volto-form-block doesn't have the concept of a save adapter so there isn't a good way to create a plugin to do something different on save. One of those two things needs to happen.
Another possible way to build this might be via plones custom user fields. You could create a content rule based on users updating their profile that stores a request in a request queue and sends an email to someone to approve that. Basically the same as what the signup adapter does but in the form of a content rule and based on user update events. The user would have to know to edit their profile to submit the request however. And volto didn't yet implement custom user schemas yet.
Or, one way to add action adapters to volto-form-block might be to do so via the content rules system. Extend content rules to have form submission events on pseudo "records" objects. It would not be an obvious UX with lots of clicks to set things up but you would have custom action adapters without having write a new framework and UI
Then you could break up what signup adapter into an approval rule condition and a user add rule action. So the content rule would be
On Form submit -> if action approved -> then add user to group
It's perfectly possible to make content rule conditions have delays in them like this implies.
Thanks @djay,
Good to be aware of ways that avoid custom content types, definitely keeps things more flexible.
I like the idea of tapping into content rules to address problem.
Thanks @yurj, haven't looked at it yet but my general thinking is to repurpose the api of a useful implementation so that I can get it to work with Volto.