You are far from the first to encounter this little puzzle. A single field with a checkbox group is easy to set up, but a report enumerating the number of times each value is selected is anything but simple.
My suggestion is to get rid of the single field. Replace it with a related table where you select each option by creating a separate related record with one of the values from your value list. This is most easily set up with drop down lists/pop up menus in the portal row, but it's possible to use buttons and conditional formatting (or a calculation field) to produce what still looks and functions like your check box group but in reality is creating/deleting records in the related table.
With that related table, you can then base your summary report on the related table to enumerate how many times each value was selected.
Oh I see - so I can have a "modules used" sort of table to track which module and link it to an event ID, and have as many rows in that table for an event as are needed. So to continue my little example,
Modules Table (instead of Events table)
Event ID 1 - Module A
Event ID 2 - Module B
Event ID 3 - Module A
Event ID 3 - Module B
where the event id is a key to connect the tables. And then the reporting can happen as it does for any other related table.
Thanks for this - I never would have guessed that adding another table would actually make things simpler and not more complex!
I'm giving this a test run and can't seem to get a new record added via a portal? Portal is on Event record, looking in on records from the Modules table, filtered by relevant event id. I can edit the Modules records, but not add new ones. I have a feeling I'm missing something obvious here!
Another option might be to leave the checkboxes, but add a script that add/removes records from Modules on check/uncheck events.
Have you allowed 'add new records via this relationship' when setting up the relationship?
Fixed now :)