Membership Plugin - Members Classes & Levels (Level to Level Rules)

Hello WPMUdev team,

The Membership plugin can be used to create classes of members, not just levels....

But to effectively manage multiple classes in one network, we need to be able to define access in a way that can effect how member classes can interact with each other (to achieve this we need to be able to control what content can be accessed by the membership class that created it).

Allowing custom interactions between classes of membership would expand our ability to create functional networks around a specific topic made up of members with different needs surrounding that topic. Of course being able to create an integrated network of networks would be helpful for this too.

Example of Classes:

1) Customers
2) Retailers
3) Wholesalers

Right now we are limited in ways can customize how members interact. If there were a good way to define access that was dependent on ones membership class and the membership class of other members, then we could better customize their interactions.

Some examples:

• Customer class members can see and access blogs or groups created by a Retail class members for them.

• Customer class members would have access to a directory of Retail class members, but not to a directory of Wholesale Business class members.

• A Retailer class member could see and access blogs and groups created by members of the Wholesaler class, and vise versa, while excluding the end Customer class members.

By controlling access by a creator's Class and Level, then wholesalers and end customers could be shielded from each others blogs, activity, groups, etc.

Why bother? – Imagine having petstore.com. Your initial goal was to help pet stores interact with their customers, but in the creating this pet store community you now have a niche market of pet store owners. These pet stores are in themselves, specialized customers that have their own product and service provider requirements. It would be a benefit to the pet stores and those that want to sell to them to help facilitate the connection. This creates and opportunity for additional of revenue for the network.

To go a little further, imagine you own pets.com. This is also a vertical market but less specific. So you might have the following classes that need to interact in different ways.

• customers
• pet stores
• pet product wholesalers
• pet product manufactures

You could create four separate networks on subdomains for different interactions :slight_frown:

petowners.pets.com
petstores.pets.com
petstore-supplies.pets.com
pet-product-manufactures.pets.com

But the pet stores and wholesalers would each need memberships on two separate networks, one for selling and one for buying. This is messy, and certainly not an ideal way to meet the distinct yet interwoven needs of different classes around a particular topic.

Putting multiple classes together in one well designed network simplifies things and makes things more convenient. It adds the potential for greater functionality thereby allowing for an increase in usefulness and value. It creates many interesting opportunities to profit from the facilitation of distinct interactions between classes.

Being able to serve multiple classes increases the number of services that can be provided surrounding a particular topic means - more potential revenue.

Classes and Levels go well together too:

- Free Customer Membership
- Premium Customer Membership

- Free Limited Pet Store
- Pet Store Plus
- Pet Store Ultimate

- Pet Store Supplier
- Pet Store Supplier Pro

- Pet Product Manufacturer
- Pet Product Manufacturer Pro

Here are some examples of how a developer could create member benefits by using the interaction between two or more classes:

1) A developer could build a large network of Pet Stores by offering valuable free services (ideally valuable to the pet store but low cost to the developer). This would give the developer control over a 'Pets Store' market, which would be of significant interest to pet stores suppliers. Pet store suppliers can become paying members so they can connect with the Pet Stores.

2) A developer offers Pet Stores members a membership upgrade in exchange for them offering discounts to Premium Customer Members. The Customer class can then pay for a membership that get the Pet Store discounts.

3) The Pet Store Suppliers get a membership upgrade if they offer a discount to the Pet Store members. The Pet Store members can then pay for an upgrade to get these discounts from the pet store suppliers.

Here is another example of a benefit of using one multi-class network, or integrated network of networks:

Automatic resupply chain - where a network customer orders product X from a network pet store, this pings the wholesaler to add one more product X to pet store's next order, which pings the product manufacture to add one more products X to the wholesaler's next order.

300 customers order Product X from three different network pet stores.

100 pets stores order product X from wholesaler A.
100 pets stores order product X from wholesaler B.
100 pets stores order product X from wholesaler C.

Manufacturer of Product X produces 300 units and ships to wholesalers A, B & C....

________________________________________

Another nice option would be to allow a class to choose from an approved list of other classes to display to.

Example: Wholesalers can create blogs or groups and select check boxes for who can access a blog or group they create. A logical admin approved check list to choose from would be 'Pet Stores' and 'Manufactures'.

They may in this case create:

– a blog and group for Manufacturer members to find and interact with them.
– a blog and group for Pet Store members to find and interact with them.

The combined defaults of their Wholesaler class settings and the settings for other classes would not allow their blogs or groups to be seen or accessed by end customers or other wholesalers.

Having the ability to control what content can be accessed by the membership class that created it, we could define access that effects how member classes can interact with each other. This will allow us to effectively manage multiple classes and class levels in one network and provide awesome functionality.

This class interaction functionality could be added by adding a classes option to the membership plugin. The management could be achieved by applying rules to the classes and additional rules to the levels under each class.

Even if the option to create classes were not added to the Membership plugin, the ability to define positive and negative rules for membership level interaction could be used to achieve class interaction functionality by having rule options for levels.

(Admin determines access the level has to things created by, or related to other levels)

LEVEL INTERACTION RULES

Positive:

This level can access:
– Some other class level 1
– groups
– blogs
– etc...

– Some other class level 2
– groups
– blogs
– etc...

Negative:

This level cannot access:
– Some other class level 1
– groups
– blogs
– etc...

– Some other class level 2
– groups
– blogs
– etc...

(Admin determines which levels the level can choose to give access to which features)

LEVEL INTERACTION CHOICE RULES

Positive:

This level can control access to their:
– groups for
– Some other class level 1
– Some other class level 2
– Another class level 1
– Another class level 2
– blogs for
– Some other class level 1
– Some other class level 2
– Another class level 1
– Another class level 2
– etc for...

Negative:

This level cannot control access to their:
– groups for
– Some other class level 1
– Some other class level 2
– Another class level 1
– Another class level 2
– blogs for
– Some other class level 1
– Some other class level 2
– Another class level 1
– Another class level 2
– etc for...

The access, restrictions and choices should be able to be applied to a members own level too. This way a member of a class can be allowed or restricted from seeing, or accessing content from members of the same class.

Example of Same Level Rules, and of Choices:

• Some developers might want client members to see a description of their service and their prices, but may not want other developers seeing this and being able to undercut them.

• Some developers might want other developers as clients. So they would want the option to allow other developer to view their services and prices.

Allowing control of access to other members information, content and creations based on level or class will open up many intriguing network design options for WPMU DEV members.

Cheers,
Sean