organization model
bobhaugen
and projects.
So am I (as he knows). Mine is for cohousing groups, starting with
one particular cohousing group, and generalizing from there if more
groups get interested.
The org model starts out pretty general. Might be interesting to
others, including jtauber, at this stage.
The purpose of this message is to announce that my model is probably
at its maximum stage of generality. It gets more particular (to one
cohousing group) from here on (starting Monday).
So if anybody is interested, if you export it now (get r8 later), you
will get the most general model.
It includes Org,
OrgType (to differentiate types like Tribe, Project, and in the case
of the cohousing group Circle, Committee, Subcommittee and
Household),
OrgPosition (a user in a role),
PositionType (like President, Secretary, etc.),
Meeting and MeetingAttendance (you might want to ditch these),
and from Pinax Projects, Topics, Tasks, Wikis and ThreadedComments.
The Type objects are a little bare now, but later they will become
extension points for behavior variations etc.
The whole project is dependent on Pinax. Orgs, however, could become
a reusable app.
If anybody is actually interested in cohousing apps, please ask to
join the project.
James Tauber
as much as possible.
I just posted a blog entry to my personal site:
http://jtauber.com/blog/2008/11/09/groups_tribes_and_projects_in_pinax/
where I confuse myself about the relation between Org, Org instances,
OrgType instances and a 4th type (a collection of semantically related
Org instances, e.g. "programming language tribes")
After revisiting this email, I'm fairly sure that my first 3 bullet
points in that blog post do correspond to Org, OrgType instances and
Org instances respectively.
Thoughts welcome.
James
bobhaugen
> where I confuse myself about the relation between Org, Org instances,
> OrgType instances and a 4th type (a collection of semantically related
> Org instances, e.g. "programming language tribes")
>
> After revisiting this email, I'm fairly sure that my first 3 bullet
> points in that blog post do correspond to Org, OrgType instances and
> Org instances respectively.
technically be yet another set of OrgType instances if people want to
break them down that far, or they could be categories or tags. I'd go
with tags.
I think if you start to subdivide in OrgTypes, they will get too
complicated to navigate, whereas a small number of OrgTypes could go
on tabs.
And you can't really have both Tribe and also Programming Language
Tribe as OrgType instances unless you also have parent and child
OrgTypes, and as dougn says in your comments, 'that way leads
madness'.
bobhaugen
taken.
What's a better alternative? I didn't spend much time on the name,
wanted to get something up and running quickly.
The point of OrgType, though, is that the public-facing names are
configurable. Many of the people I work with hate Tribe, for
example. Not gonna please everybody with any set of names.
Nicola Paolucci
As requested by James I packaged the first of the modules I wrote for
http://tuttivisti.com.
I did not polish it since I understand you started a rewrite of the
account module.
http://github.com/durdn/easyopenid/tree/master
I'm here of if you have any question, but as you'll see it's nothing
ground breaking.
Regards,
Nick
greg newman
greg newman
http://20seven.org
James Tauber
funnily enough, "new-groups-app").
My current working name for the main model is Group.
The first design decision I'm hitting up against is whether slugs
should be unique across all groups or just scoped to the group type.
Option 1. All Groups
Has the advantage that we can more easily provide for linking to a
group regardless of type. e.g #foo in a tweet could mean a tribe or
project or whatever, without need to disambiguate.
Disadvantage is we couldn't for example, have a tribe and project both
called "pinax". To be honest, this doesn't bother me -- we can just
call the project "pinax-dev" or whatever.
Note that even if we go with this, I would still propose URLs that
look like /groups/project/foo/ rather than /groups/foo/ although this
option allows for both (and we could let the site-developer ultimately
pick their URL patterns)
Option 2. Scoped to Group Type
Only real advantage is it's easier to pick slugs because there's less
chance of a clash. It might surprise the user if they are creating the
very first tribe and it says the slug is taken.
Obviously we would have to use the *type* slug in any URLs and it
would make difficult doing things like linking to groups easily in
wikis or tweets without some extra prefix.
Thoughts?
Let me also through in Crazy Option 3: don't even allow group slugs to
be the same as a username. That way @group could be used instead of a
different siglum for users versus groups.
James
James Tauber
Should the templates be parameterized or should we expect a site-
developer to just create per-group-type templates?
I certainly expect views to be parameterized otherwise it's really
only a shared model and I think the point is to have better reuse than
that.
e.g. say a site has group types 'project' and 'tribe'.
Option 1. Single Set of Parameterized Templates
There is a single group_list, group_create, your_groups, group_detail,
etc each of which is parameterized for the group type.
This means that more is done either in the database or settings files
to declare various text to be used for a particular group type and
gives less flexibility if you want different layout or content
depending on group type.
Option 2. Individual Templates
The site developers have to provide project_list, tribe_list,
project_create, tribe_create, your_projects, your_tribes, etc, etc
which will be a big DRYolation. The only benefit is if you want more
fine grained control on templates on a per-group-type basis.
Thoughts?
James
James Tauber
Should a group type (e.g. "project" or "tribe") be a row in a
GroupType table OR purely a Python object configured in a Python file?
Personally, I prefer the latter -- I don't like configuring my site
via the database, although we may eventually want to allow both
approaches. Remember, group *type* creation is intended to be a rare,
development-time activity no different than setting up urls.py, etc)
The only different this makes to the Group model is instead of a
foreignkey to a GroupType model, it will just have a CharField which
will contain the type slug which will be used for a lookup in some
group type dictionary. Having that slug in the table will also prevent
unnecessary db joins in many cases.
James
Rock
prefix the slug if desired.
Templates -> Individual templates. Note that this doesn't necessarily
leave the matter to the site developer since I expect several group-
based apps to become available (at least as examples) and those apps
could provide more detailed templates if desired.
Group Type -> Pure Python. I buy your explanation.
James Tauber
On Nov 28, 2008, at 2:25 PM, Rock wrote:
> Slug -> All Groups. Simpler and a group implementor could override to
> prefix the slug if desired.
Good point. It was my preference anyway :-)
> Templates -> Individual templates. Note that this doesn't necessarily
> leave the matter to the site developer since I expect several group-
> based apps to become available (at least as examples) and those apps
> could provide more detailed templates if desired.
Yes, you're right -- some group types could come out of the box. But I
still worry about violating DRY having a different template for
creating a tribe versus creating a project versus creating
my_group_type_1 versus creating my_group_type_2.
Perhaps I'll define to one template for all types but allow template
names to be overridden in the group type configuration.
> Group Type -> Pure Python. I buy your explanation.
We can always change things based on feedback, but I'll at least start
off this way.
James
Doug Taylor
More design discussion on the new groups app...
Should a group type (e.g. "project" or "tribe") be a row in a
GroupType table OR purely a Python object configured in a Python file?
I've been throwing around an idea to isolate generic app relations
to the settings file (or elsewhere). Something like.:
APPTREE = [{
'name': 'Project',
'model': group.Group,
'url': '/project', # /project/<slug>/
'children': [{
'name': 'Task',
'model': task.Task,
'url': '/task'}, # /project/<slug>/task/<slug>/../
{
'name': 'Wiki',
'model': wiki.Article,
'url': '/wiki'},
{
'name': 'Issue',
'model': issue.Issue,
'url': '/issue'},
{
'name': 'Repository',
'model': gitosis.Repository,
'url': '/repo'},
]},
{
'name': 'Tribe',
'model': group.Group,
'url': '/tribe', # /tribe/<slug>/
'children': [{
'name': 'Wiki',
'model': wiki.Article,
'url': '/wiki'},
]},
]
Other parameters to the generic applications could then be added as
needed to the appropriate dict in the tree. Note that 'Tribe' and
'Project' both use the same model but have varying names and generic
apps tied to them as children. I guess the 'name' would have to be
stored in the model to distinguish between GroupTypes?
Doug
James Tauber
We're going to have to give this a fair amount of thought.
I don't want the entire configuration of Pinax to work this way, as I
worry it's too distant from the normal way Django does things and I
want Pinax to always feel like normal Django.
However, there are some interesting ideas here which might be useful
in the specific context of groups. I've already started to go down the
path of a dictionary (keyed off group type) of dictionaries
(properties of that particular group type). I have lots more to do
before I see how that turns out, though.
I'm a little nervous about having an alternative way to specifying
URLs to what Django already provides, although I do like the notion of
specifying paths relative to the URL of some instance.
The path forward isn't going to be easy. In some areas, like generic
groups, we are going to have core code which a site-developer is going
to want to configure. But we want that to feel as much as possible
like Django development.
I certainly welcome input from others.
James
bobhaugen
Experience report: as I continue to work out the app for my cohousing
group, they invent a new group type every week. If they want to keep
this up, they'll (and I'll) be glad I got the tyoes in the database.
I got a default template for most group types, and then one
specialized one (so far). I expect to have more specialized templates.
James Tauber
I'll try to get a little further on my branch first and then see how I
might be able to support your cases (or even just use your code)
James
bobhaugen
> This is good to know.
>
> I'll try to get a little further on my branch first and then see how I
> might be able to support your cases (or even just use your code)
my cases, which continue to multiply like bacteria. So do what you
think will be generally useful.
By the time you get done, my code will have evolved into something a
lot more custom to the particular type of group. But it will continue
to be available at the same place if you want to check it out again.
James Tauber
1) reduce the duplication of code between Tribes and Projects
2) make it easier for new types of "Groups" to be created that have
different combinations of features from tribes and projects, possibly
with additions of their own
Note that while I use the term "Group" in this email we'll probably
ultimately go with a different name. With that warning gone, I'll drop
the scare quotes.
My shift in thinking from "endo" to "exo" means that instead of a
table of GroupTypes and a single Group table, each new group type will
just be a Django model. In other words, in Pinax 0.7, there will still
be a Tribe model and a Project model.
The change from 0.5 to 0.7, however, will be that pieces like topics
and tasks will be independent of tribes and projects and reusable
apart from them. Furthermore there will be support for a variety of
membership models including:
1. anyone can join
2. users can request to join but must be approved
3. users can be invited by the group admin but must accept
4. users can be added by the group admin
(Note these are options available to a *developer* -- whether a group
creator has a choice is up to the site developer)
The first step in all of this is breaking topics out of tribes and
projects and putting them in a third app where they can be shared by
tribes, projects and whoever else wants to use them. (The same applies
to tasks)
There is already precedence for this in wikiapp.
But I wanted to raise some of the challenges in breaking out (just for
example) topics to elicit feedback and possible alternatives.
1. the explicit foreign key to Tribe or Project must be changed to a
generic foreign key
I don't think this is an issue -- we may want to follow the lead of
wikiapp in supporting the GFK being nullable too for sites that might
want top-level topics
2. will topic URLs be group-type-specific?
The simplest way is not, but that is probably not desirable for many.
wikiapp does get around this and does include the group slug in the
URL for a wiki article. We could do the same. There may even be a
common pattern we can document.
3. will topic views be group-type-specific?
I'm not even sure how to make this so if we wanted to, short of just
dispatching to different functions based on group type which I guess
would work. But maybe we don't even need to do this. It depends if the
topic view needs to do group-type-specific things. Wikiapp just has a
single view regardless of whether its a tribe wiki, project wiki or
whatever. The group is always available. It does mean that all groups
need to follow certain conventions or there need to be adaptor
functions for doing things like checking membership and checking
permissions. Again, we could note the common patterns in wikiapp and
reuse them (there may even be code we can factor out)
4. will topic templates be group-type-specific?
wikiapp does not do this but I think we might need to support it. The
fact wikiapp doesn't do this can be seen in the fact that if you go to
a wiki page under a tribe, the tribe tab is no longer selected. I'm
not sure how to address this short of the view looking for a template
called (say) <group_type>_topic.html before falling back to topic.html
I definitely welcome thoughts on this.
5. will topic notifications be group-type-specific?
When someone replies to a topic in a tribe now, the topic creator gets
a "tribes_topic_response" notification. In 0.7 we would have two
choices: just have a generic "topic_response" notification (i.e. you
can't control tribe and project responses separately) OR support
notification type label conventions like "<group_type>_topic_response"
3, 4 and 5 all talk about naming conventions which can sometimes feel
a bit too magical but I'm not sure of a better way.
I welcome your feedback and thoughts
James
daonb
>
> 1. anyone can join
> 2. users can request to join but must be approved
> 3. users can be invited by the group admin but must accept
> 4. users can be added by the group admin
process of adding a new member. The core policy is the same - new
members must be approved by an Admin. As for 4, IMHO the user must
always accept a new membership offer.
I would also like to see the Group membership model a more complex
membership models. Here's my code:
class Role(models.Model):
group = models.ForeignKey(Group, null=True, blank=True,
related_name='roles') # use null for global roles - e.g.
maker, guest
title = models.CharField(_('relation'), max_length=30)
default_permissions = models.ManyToManyField(Permission,
verbose_name=_('permissions'), blank=True)
class Membership(models.Model):
# stuff needed by the ManyToMany relationship
user = models.ForeignKey(User)
group = models.ForeignKey(Group)
# Membership attributes
joined = models.DateTimeField(_('joined'), default=datetime.now)
role = models.ForeignKey(Role, verbose_name=_('role'),
max_length=30)
merits = models.IntegerField(default=0)
permissions = models.ManyToManyField(Permission, verbose_name=_
('permissions'), blank=True)
Keeping track of merits and the joined date, allows Group to support
two types of Honor policies - oligarchy and meritocracy. I'm not sure
yet what these policies mean, but at the very least the can control
the order by which group members are views.
> ...
> projects and putting them in a third app where they can be shared by
> tribes, projects and whoever else wants to use them. (The same applies
> to tasks)
aka categories aka sub-groups. How about adding a parent field to the
Group model, so that topics can be implemented as a sub-group? This
will allow large groups to be broken down into interest areas each
with his own members. If I look at an open source project as a use
case, one sub group can be 'users' and the other 'core development'.
Obviously the users subgroups will have a lot more members.
> 1. the explicit foreign key to Tribe or Project must be changed to a
> generic foreign key
>
> I don't think this is an issue -- we may want to follow the lead of
> wikiapp in supporting the GFK being nullable too for sites that might
> want top-level topics
>
(Group)?
> I welcome your feedback and thoughts
so it to keep a log of content and membership changes and display a
timeline of events. here's the code from my models.py:
class AssociatedContent(models.Model):
"""
convecting groups with content. Notable fields (shamelessly copied
from django-schedule):
distinction - what makes this specific association distinct?
inheritable - do all sub-groups inherit this content?
"""
group = models.ForeignKey(Group)
content_type = models.ForeignKey(ContentType)
object_id = models.IntegerField()
content_object = generic.GenericForeignKey('content_type',
'object_id')
distinction = models.CharField(_('distinction'), max_length = 20,
null=True)
inheritable = models.BooleanField(_('inheritable'), default=True)
class GroupsLogEntry(admin_models.LogEntry):
group = models.ForeignKey (Group, related_name='log')
bobhaugen
daonb's.
Members have roles, groups have events (of more than one type).
I have not abstracted roles and permissions into relationships with
other classes yet. So far, all in code, because the requirements are
still changing too much - including whether the same member can play
more than one role.
If the main Group class is to be inheritable, it would be good to add
some code like this:
http://www.djangosnippets.org/snippets/1034/
daonb
> daonb's.
>
> Members have roles, groups have events (of more than one type).
>
future events calendar like the one defined by django-schedule?
> I have not abstracted roles and permissions into relationships with
> other classes yet. So far, all in code, because the requirements are
> still changing too much - including whether the same member can play
> more than one role.
"unique_together = ('user', 'group')" in my Membership model.
> If the main Group class is to be inheritable, it would be good to add
> some code like this:http://www.djangosnippets.org/snippets/1034/
I didn't need to lookup all the groups. I could be wrong, but Pinax
has no page for displaying both Projects and Tribes and I don't see
the need.
I've also defined two template_tags so far:
- {% show_member_actions group user %} - to display the manage | join
| ask to join | leave links based on the user's relation to the group
- {% show_members group %} - to display all members of the group
I'm presenting my work tomorrow to the local Django group tomorrow-
http://groups.google.com/group/pyweb-il/web/pyweb-3 - so if you're in
the area (50 miles north of gaza), we're going to have good people and
free beer!
bobhaugen
> > Members have roles, groups have events (of more than one type).
>
> Not sure I understand 'events'. Are you talking of log-type events or
> future events calendar like the one defined by django-schedule?
> I don't like giving a member more than one role and I do have a
> "unique_together = ('user', 'group')" in my Membership model.
first phase, and the second phase will introduce some new
requirements. Some of them will be messy. Hope to continue to avoid
multiple roles, but we'll see.
Wish I could make it to your presentation, but it's a little too far
from Chicago...