[geeklog-devtalk] plugins and moderation

[Blaine Lang]

I floated the idea about a new API call for notification a few months ago. This came out of my work on the Forum plugin and since then have written several other plugins with notification functionality. When I developed glMessenger as a GL private messenger plugin, I saw the need to allow users the option of specifying how they wanted to receive site notifications.

glMessenger allows users to specify the notifications be received as private messages. This allowed users to manager their site communications. They can of course still enable email notification of new messages from glMessenger but they would still have all Geeklog notigfications inside glMessenger. 

Forum 2.3 uses the new notification function that I wrote as do other client specific projects that I have completed.

msg_sendNotification($user,$subject,$message,$type="")

This function currently only supports type of mail or glmessenger but checks the extended user preference for their personal option. This function could be extended to check other registered notification services.

On Moderation: I added moderatation to the forum plugin for a client. It allowed the admin to setup moderation (per forum) on just new topics or full moderation of all posts. I hope to release when I get some more time to finish of the 2.3 release. I didn't have any problems and may not fully understand your suggestions without getting my head back in the code again.

Regards,
Blaine

glMessenger Datasheet:
http://www.portalparts.com/staticpages/index.php?page=20031129163701316


  ----- Original Message ----- 
  From: Wim Niemans ri 
  To: geeklog-devtalk at lists.geeklog.net 
  Sent: Friday, February 27, 2004 1:58 PM
  Subject: [geeklog-devtalk] plugins and moderation


  In an earlier message:


  >>PLG_notify_user('type_of_notification') for sending specific email


  >Hmm, what exactly is this supposed to do? As of Geeklog 1.3.9, plugins
  >can easily use COM_mail to send emails.


  The use of it would be to allow people to send on well defined notifications their own template. Dirk made some example with the welcome email.
  The most convenient way is, btw, to have the text for these emails in the database, so one could send an email in the language of the recipient.
  I am thinking of a plugin doing these kind of house-keeping. But maybe there is a better way to get this into the core.
  ---------


  In another earlier message:


  >>PLG_render_story('story_text') for extra runtime amendments of the 
  >>story, f.i. adding links (glossary) or applying styles.


  >Sounds like an interesting idea. It could be implemented similar to what
  >we've introduced for extending the user profiles in 1.3.8.


  The use of this is, off course, adding links to the text.
  They will show up in the what's related block also and smooth.
  Another use would be bad-word-censoring, highlighting (see search), rotating ads and on....


  ---------


  And a fresh proposal:


  The moderation engine is pretty sophisticated.
  Another use of this engine could be archival of user, stories etc. having the GL table as submissiontable and the archive as GL table.
  I'm thinking of using it in the contacts plugin, to automatically archive contacts after moderation. However, for some other bells to GL, there is a pitfall.


  The result of PLG_getmoderationvalues is blindly copied into the sql to dbdelete and dbcopy. There is no check if the table_names do exist, nor if the $fields array is empty. A plugin could even delete entries in the users table, mentioning the 'users' table as submissiontable.


  I do have several functions that are triggered thru the moderation engine. However I do *not* have a submissiontable. F.I. getting a list of members 1 week before their birthday, or with events older than 3 months. This list can go on and on....
  Adding a check in admin/moderation.php (before db_COPY and db_Delete):
  ---->   if (($table == $submissiontable) || (empty($submissiontable) || (empty($fields))
  would be a must-have, not only for testing purposes.
  I remember I pathed them partly into lib-database.php. Unfortunate I lost these changes when installing 1.3.9.RC1.


  Finally I noticed that PLG_showModerationList() is not a plugin API and can be contained in admin/moderation.php only. Called from anywhere but admin/moderation.php results in an error (unknown function 'itemlist').
  Maybe the plugin class could use a method 'addSubmissionAction' if we don't want to approve/delete. Example: Commit or Invoice or just Acknowledge.
  Anyway, a prototype for such transactional additions could be delivered if GL would consider this as core.


  Cheers,
  Wim Niemans
  _______________________________________________ geeklog-devtalk mailing list geeklog-devtalk at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devtalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://eight.pairlist.net/pipermail/geeklog-devtalk/attachments/20040227/a769f188/attachment.htm>