|# 10 Feb, 2016 15:35|
A Tendenci user was inquiring about entities so starting this thread to get the conversation going.
|# 10 Feb, 2016 16:28|
I have a basic level of understanding so please chime in if you have corrections or additions to the below.
Entities and Groups are ways to create clusters on your website.
Entities are related to the business logic of your site.
Groups (subclass of entities) are related to user permissions and outgoing communications
To Edit Entities on Your Site:
Edit entities via the admin backend or via direct link at www.example.com/admin/entities/entity/.
Edit groups via set up on the admin backend of via www.example.com/admin/user_groups/group/
Identifying your groups and entities
To identify what entities and groups to set up on your Tendenci site you'll want to ask yourself the following questions:
Groups: Which clusters of users need to have specialized site permissions? Which clusters of users will I want to send communication to?
Entities: Which clusters are driving in revenue that I would want to examine for reporting and analysis? Which cluster would I want to track for general reporting?
Python website resource on entities: https://pypi.python.org/pypi/django-entity
|# 11 Feb, 2016 10:42|
Quoting below description sent to me by user eschipul on groups and entity. (Minor formatting changes by bleven)
EAV, Entities and User Groups in Tendenci
Entities are pointers and used to take a snapshot of a transaction at the time it occurred. This is for financial reporting primarily.
Usergroups are more amorphous and used to organize people within an association or online community for things like special interest groups, newsletters, notification opt-in or opt-out, etc.
Factors and Uses of Usergroups
Opt-In or Opt-Out Users can typically control if they choose to join a group or not. They can unsubscribe from a committee's notifications for example. Or join a group that receives notifications of new job listings, and logically they might unsubscribe from that group once they obtained employment.
Filtering more efficiently than tags Usergroups are for organizing data and are much faster than tags. So you can filter|usergroup=1 on the right hand column of a template for example. Searching for a pk id is faster than searching for indexed tags and works immediately as opposed to waiting for the next chron job to index the content.
Relationship to Entities usergroups are required to be tied to an entity, although technically a site can have one and only one top level entity of 1 which is the site name. a more typical setup is shown below.
Technically from a computer science perspective Entities are just pointers that follow the EAV design pattern. Usergroups then are tied to entities.
Examples of entities and groups on a site
A super simple site would be: Entities - www.example.com/admin/entities/entity/ 1) The Association - (entity 1, parent entity 0)
Groups - www.example.com/admin/user_groups/group/ 1) The Association (group 1, entity 1, type REPORTING)
A more realistic organization would look like this:
Entities - www.example.com/admin/entities/entity/
In this scenario, because a person can join or leave a usergroup mid year, you need a constant to track invoices which is what entities are for.
It answers questions like "How much income did our Study Groups bring in last year?"
You can't use usergroups for that.
The reason is if someone left the usergroup in November that studygroups budget for the following year would be based off of incorrect data. The invoices reports are tied to entities so suddenly all of those invoices (if it were allowed) would be credited to the parent association instead of a child entity of the parent association.
For many clients who do high dollar sales, how to allocate 1M in budgets to the various committees, study groups and scholarship committees, becomes a really big deal.
You have to know that the "Golf Committee" brought in 200k for the scholarship fund, but they will need a 50k budget in the first quarter to make a down payment for the golf course to reserve it for a tournament in the third quarter.
So why not just use entities and skip requiring usergroups?
Because we still need flexibility. Usually usergroups are usually tied one to one with entities that relate. Some organizations just make the top entity the same regardless if they aren't worried about allocating funds or do it through a different system.
A typical organization, again using the example above this would look like something like this:
Groups - www.example.com/admin/user_groups/group/
Take the "SECRET Anonymous" group. They don't consider themselves a committee and don't want to be reported as such (human issue, not software). So they just go under the parent entity 1 by choice. Remember, these are humans and the software should bend to their needs while subtly not letting you break reporting needed by the AE or CEO.
Note a few things about this.
We can't quite accommodate everything.
Joint events cohosted by two committees. The pointer model doesn't support this so sometimes a client will make a special group called "Committee A and Committee B Special Events" and put it under the reporting entity COMMITTEES and make an adjustment in their accounting system.
So it isn't a perfect system, but it is WAY faster when it comes to displaying filtered data on a web site, handles the flexibility of letting people leave or join a group whenever they want (if the client has it set up that way in global settings) and still keeps track of the money.
The structure has been in place since 2001 so it really has stood the test of time. There are other one-offs that have come up but they are extremely rare and I can tell you how we handle those for the larger associations on Tendenci (over 100k users on one site for example."