Entities

Four steps to Teams success

Entities for all services

The entities in this section are needed throughout the whole application

BaseEntity [Duplicate entity]

Almost all entites inherit from the BaseEntity – it is duplicated through all SDK projects:

CreatedDate: DateTime?
CreatedBy: User
ModifiedDate: DateTime?
ModifiedBy: User

UserEntity [Duplicate entity]

This entity is duplicated through all apps and represents a user that can be created out of graph information.
It is used if more user information is needed.

Id: string
FirstName: string
LastName: string
EMailAddress: string
JobTitle: string
ProfilePictureUrl: string

User [Duplicate entity]

This entity is duplicated through all apps and represents a user that can be created out of a token – without calling the graph. This is used in the BaseEntity to identify to track who performed an operation.

Name: string
Id: string
Domain: string

EnterpriseType [Shared enum]

This enum is shared throughout the whole App (Origin: Enterprises.WebApi.SDK)

Customer
Supplier
Own

Groups.WebApi.SDK

The following entities live in the Groups.WebApi.SDK

  • MasterdataSite
  • MasterdataGroup
  • CategoryGroup
  • CategoryDefinitions
  • Areas

MasterdataSite

The MasterdataSite comes with the following properties

Id: string
MasterdataId: string
EnterpriseType: EnterpriseType
Name: string
Description: string
MasterdataSiteType: MasterdataSiteType
AreaLocations: List<AreaLocationEntity>
PhysicalId: string; (Needed?)
SiteUrl: string
Status: ElementStatus

SubEntity: AreaLocationEntity

AreaId: string
AreaLocationStatus: AreaLocationStatus
AddedBy: User

SubEnum: AreaLocationStatus [enum]

WaitingForCreation
Created
ContentTypeSet

MasterdataSiteType [enum]

Enterprise
Site
Line
Order
Product
ProductType

ElementStatus [enum]

WaitingForCreation
SiteCreated
ContentTypesSetInAllAreaLocationsOrFinishedWithoutContentTypes

MasterdataGroup

Id: string
MasterdataId: string
Owners: List<UserEntity>
Members: List<UserEntity>
Name: string
Description: string
PrivacyLevel: GroupPrivacyLevel
GroupGUID: string
SiteUrl: string
TeamUrl: string
GroupStatus: GroupStatus
HasTeam: bool
PublishesInformation: bool

GroupStatus [enum]

WaitingForApproval
WaitingForCreation
GroupCreated
ArchivedByMicrosoft
ArchivedByGroupHive

GroupPrivacyLevel

Private
Public
HiddenMembership

CategoryGroup

  • The metadata of the group folder (as a PartDefinitionId)
  • The name of the group folder definition (could be ‚department‘)
  • A description of the definition (in case of ‚department‘ not necessary, because obvious)
  • The information if a hierarchy is allowed (for departments thats true, but projects might not have a hierarchy for example)

So a group folder definition determines what kind of context the group folder should have.
A group (type „GroupEntity“) describes a concret Office 365 Group that can be part of a group folder.
Each group in GroupHive has to have a GroupFolderId that associates it with a context. Otherwise GroupHive would not make any sense.

Hint: The term „group folder“ can also have another meaning GroupHive. Currently with a group folder we referred to objects of the „GroupFolderEntity“ class, but a group folder can also be something else.
Some of the contexts a group can live in should have not a manual, but an automatic context.
Departments, topics and projects are usually manual entities. User add, remove and edit them in GroupHivePortal.
But other entities that can also serve as group folders are not manually created. Those entities come from DataHive what might be linked to an ERP-system.
Those entities are:

  • Customers
  • Suppliers
  • Customer sites
  • Supplier sites
  • Orders
  • Lines
  • Products

In a GroupHive context we call those entities „automatic group folders“ in contrast to „manual group folders“ that are alwys objects of a „GroupFolderEntitiy“.
Those also serve as group folders, but objects of their type are not GroupFolderEntities. They have their own classes.
This appears in the components responsible to display group folders. Here an enum called „GroupFolderType“ distinguishes between those types.

Main groups and additional groups

Each manual group folder has at least one default group. This group is called the „main group“. Its a private group where all members of the group folder are added automatically.
The manager of the group folder (for example the department manager) will become the owner of the main group.
In contrast we treat automatic groups differently. This is because automatic groups have another „reasons to be“.
If someone creates a new department or topic in GroupHive he does that to create a group for this purpose.
But if someone creates an automatic group in DataHive this does not mean that it should contain a group.
It could also serve a different purpose (the master data of DataHive is leveraged by other parts or third party applications).
For this reason automatic groups do not get a main group when they are created. They are also created not in GroupHive but in DataHive (or an ERP system)
But even if they get a main group if a user clicks on „initialize main group“ this main group is not private like in manual group folders. The owner of the new group will be the person that initialized the group, but the role of this owner is not important, because everybody can join the group.
It is always a public place where all people of the enterprise can join.
This makes sense, because usually everybody in an enterprise should participate in a new customer project.
Later additional groups can be added to automatic or manual group folders. Those additional groups are not different from each other. If they are private or not, their name, their description – all this is handled by the person who creates the group.
But main groups always get the name of their group folder name (could be the department name, an order number, a serial number of a product etc…)

Areas

Another difference between automatic an manual groups are areas.
An area is a place inside an automatic main group where documents can be stored. Manual groups do not have areas and additional automatic groups also do not have them.
An area is later nothing else then a SharePoint document library with unique permissions or public permissions.
An area usually references a department (a manual group folder), but it can also be a „unique area“.
If an area is referencing a department, all members of this department will get edit permissions in this library. If an area is public all other people will also get read permissions (everyone).
If an area is a unique area, only some special people that can be defined will get permission to this document library. Unique areas are not recommended, because they might produce chaos. Its still a question if they will be implemented in the final product.

Summary

  • A group folder holds groups.
  • A group folder can be manual or automatic.
  • Manual group folders get their context with a reference to a group folder definition.
  • The group folder definition has a name and its own metadata. This could be ‚departments‘ for instance.
  • Automatic group folders get their context from the associated customer, product… (see list above)
  • Manual group folders get always a private main group by default. The owner of that group is the manager of the group folder (for example the department manager).
  • Automatic group folders do not have a main group by default. But if a user inits one, a public group is created with the init-person as owner.
  • Only automatic groups that are main groups can get „areas“.
  • Areas can be private or public and they should reference a department. Its still not sure weather unique areas should also be allowed. Maybe later.

©  2024 GroupHive