[geeklog-devel] Plugin Enhancements
devel at portalparts.com
Fri Mar 21 09:59:49 EDT 2008
Joe Mucchiello wrote:
> I just had a thought and wanted to throw it out there. Obviously this
> would be a project for 1.5.1/1.6.
> Why not add a field or two to the plugin table containing plugin
> generated groups and features ids. This serves two purposes.
> First, the plugin's uninstall becomes trivial to write.
> Second, the plugin can query this field to find it's own group ids. I
> know several plugins put this info in the vars table now. No need if
> there's a spot for it on the plugin table.
On first review, this sounds like a good idea. It would be necessary
though to also have hooks into the group admin functions that allow
these features/groups assignments to be maintained. Also the
GroupAccessBlock that I wrote a number of years ago which will
add/remove feature access rights from Core Groups or any Group is often
used. There are a number of ways that feature assignments can be
added/removed and new Groups created that would alter the initial
/* Alternative approach in general */
It may be better to create a couple new generic functions that can be
called to return all groups with feature code 'yada.edit' and to
removeFeatureCode('yada.edit') which would update all Group assignments
and featurecode records.
Plugin Order or priority is an issue that I've had to address in the
past with respect to loading common libraries provided by one plugin for
others. Solution was to copy the first record, re-use it for our nexpro
plugin and insert a new record of plugin 1. Adding plugin Order would
address that and it could be used to order the display in menu's but not
sure it has any other beneft.
More information about the geeklog-devel