Adding sesskey protection is trivial and a simple oversight, thank you for catching it. All the portfolio add buttons are handled through the portfolio_add_button's to_html method, so adding sesskey there and a check in portfolio/add.php will change all cases.

Regarding your other concern, do you have any better solution? I followed Martin's original spec for this, please see http://docs.moodle.org/en/index.php?title=Development:Portfolio_API&oldid=23088.

Also, it's not "ANY" class, those classes are all subclasses of portfolio_caller (this can easily be checked in portfolio/add.php).

(grep for portfolio_module_caller)

The other option is to create a registry of all portfolio-exportable content but I dont think there's a good way to do it. This is not limited to activity modules, whole courses could be exportable.

There isn't an easy way to provide a mapping between portfolio exporters and their file/classes, other than:

1. Keep a database table of all classnames and files - I think this is a bit unmaintanable, as it's an additional "install time" question to ask modules/blocks/questiontypes/all plugins and we have it in code anyway

2. Everytime we draw the portfolio add icon on the screen, insert a possible export location into a database table. This is also not a good idea, because just because the icon gets drawn on the page doesn't mean that the user will ever click it , and it could result in multiple inserts per page load for a case that is never triggered.

I don't think the current situation is too terrible, if we have the following:

1. added sesskey protection as per my last comment, this is np to add
2. added check that the class to call is a subclass of portfolio_caller

Also bear in mind that the data that gets passed through as callback parameters to the constructor are pretty limited in regards to their datatype, it's limited to param_alphaext, param_number and param_path. That's pretty restrictive!