Forum OpenACS Q&A: Re: How would you go about this?
However I need to get something quick and dirty up really soon so I have already installed forums and will be playing with permissions settings in a few days.
Initially I plan to block access to the forums main page to all but admin users, and provide a link in the member 'workspace' to the forum associated with the member. This means that the admin user can get at all of the forums but each user can only get at their own. This will do for now because my current requirement is only for secure messaging between admin and users but a full solution should cover messages between users also.
My thoughts for the bigger better version:
- I think that the guts of the functionality is already in the forums package and so any new module ideally will be an intelligently modified forums package. Maybe even a mode of operation selectable by setting a parameter in the forums package. (Each message area should be called something other than a forum to make the distinction clear - i.e. change nomenclature).
- A parameter should determine whether or not a private message area is automatically created (accessible from the member 'workspace') when a new user registers.
- The page that each user sees when navigating to the root of the mounted module should be user specific and show/list message areas that they own. Navigation of message areas beyond that point should support the use of acs categories.
- There should be a parameter setting to grant the option for each user to be able to set up private message areas at will and specify which other parties can read/write etc.
- The setting of permissions will be compliant with the norms associated with acs groups and parties.
- Registered users should be able to send messages to other users private message areas (if they permit that) by referring to the 'contacts' package (currently under development by Mathew Geddert) and selecting 'send a private message to ...' (this should probably be a service contract implementation so that it can be included in other apps such as the logger, project manager and the registered user directory). The service contract implementation would perform the task of finding the user_id of the user that you want to send a message to and managing the message entry forms. This service contract should also handle the process of authorising the recipient to reply to you in your own specified private message areas. These inter-user features should be able to be switched off by parameter setting.
Effectively then each application (such as contacts or contacts-lite) would have to provide a service contract implementation for the secure messaging system. We would need to define the service contract as part of the scoping out process of the secure messaging system.
What do you think?
