Instead of watching movies and sleeping like most people do, I worked on Edit Flow for about 7 or 8 hours of my 12 hour flight to Spain yesterday and today. One piece I accomplished was completely refactoring Usergroups. Initially, the requirement was to drop usage of usermeta for storing user to usergroups relationships, but I ended up rewriting about 80% of it.
Mo suggested registering Users with the Usergroup taxonomy to manage the user to usergroups relationship. After writing all of the code to support that and then having it inexplicably cause bugs, I realized this approach won’t work because Users and Posts have separate unique ID columns (e.g. if you have $user->ID == 1 and $post->ID == 1, the relationship to the taxonomy will conflict). Instead, I’ve opted to store the Users in a Usergroup data in a JSON-encoded term description field and abstracted a couple editorial metadata methods to make this available to all classes. I’ll be moving editorial metadata to this as well.
All of the Usergroup management views are functionally complete (create a usergroup, add users, remove users, and add users to a usergroup from the edit profile view).
For the post subscription functionality, I’m seriously considering moving the code to the notifications modules and renaming it as “subscriptions.” Conceptually, this fits better within the new modular paradigm for Edit Flow. If usergroups were deactivated, the subscription/notification functionality would still be available. Furthermore, we can then also use Usergroups independently of email notifications (e.g. for permissions management, building custom views in the calendar based on Usergroup, etc.)
Any feedback, opinions, or things I’m missing?
