+ Start a Discussion

Why break the security model on Chatter?

Apex code (and triggers) run in system security context unless 'with sharing' is specified and that works great and allows us to control things. However Chatter completely ignores this paradigm and has a security ruleset of its own which we cannot tweak or configure. Namely even though the code runs in system context you cannot insert a FeedPost into private groups unless running user is a member and there is no way to allow this?! Why the duality? Why is the existing security scheme bad for chatter?


Namely this prevents us from  posting custom notifications into special team's private groups when a certain condition happens on a record (and caused by people who should not have read access to other stuff in the private group), but the usability being blocked does not stop there. Given that Apex does not allow user impersonation there is absolutely NO way for an apex code/trigger to generate and insert a message into a group unless the record change is caused by the user already in the group (which kind of defeats the whole purpose of bringing it to groups' attention).


There's been discussions in the past of allowing groups to optionally accept posts from non-members.  (Some private groups may not wish non-members to be able to post so it's perhaps not a suitable default).  You might wish to post that to IdeaExchange or vote it up if it's already there.


There is the ability in Chatter to post as another user from a trigger.  So your trigger could post these announcements to the group as from the group owner.  Just create your FeedItem entity and set the CreatedById field to be the author.  Note this requires version 21.0 or later.


See the API documentation for more details:  http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_feeditem.htm