You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This RFC proposes a new user model that can handle all current use cases, models the current membership system accurately, and introduces more flexibility for future use cases.
10
10
11
11
## Motivation
12
12
13
-
Why are we doing this? What use cases does it support? What is the expected
14
-
outcome?
15
-
16
-
Please focus on explaining the motivation so that if this RFC is not accepted,
17
-
the motivation could be used to develop alternative solutions. In other words,
18
-
enumerate the constraints you are trying to solve without coupling them too
19
-
closely to the solution you have in mind.
20
-
21
13
The SSTAA App Platform has gotten many feature requests, such as check-ins, event management, and even facility booking. In its current state, the user model is not a proper representation of the use cases that SSTAA needs to handle, and was designed only to support the membership tracking use case.
22
14
23
15
This led to workarounds and hacks to get the job done. In SSTAARS and Homecoming 2024, every user which registered for the event was assigned an `Ordinary` membership type, which is completely inaccurate. This is because the user model expected every user to be a member of SSTAA, which is not the case for events.
@@ -30,12 +22,6 @@ These are some of the current limitations experienced by the current model. More
30
22
31
23
## Detailed design
32
24
33
-
This is the bulk of the RFC. Explain the design in enough detail for somebody
34
-
familiar with React to understand, and for somebody familiar with the
35
-
implementation to implement. This should get into specifics and corner-cases,
36
-
and include examples of how the feature is used. Any new terminology should be
37
-
defined here.
38
-
39
25
```mermaid
40
26
---
41
27
title: Class Diagram
@@ -97,40 +83,47 @@ classDiagram
97
83
}
98
84
```
99
85
100
-
## Drawbacks
86
+
In this new user model, two entities are created for user and member. All SSTAA members are users, but users may not be SSTAA members.
101
87
102
-
Why should we *not* do this? Please consider:
88
+
It also introduces various other user types aside from the membership system, such as `Employee`, `ServiceAccount`, and `SystemAdmin`.
103
89
104
-
- implementation cost, both in term of code size and complexity
105
-
- whether the proposed feature can be implemented in user space
106
-
- the impact on teaching people React
107
-
- integration of this feature with other existing and planned features
108
-
- cost of migrating existing React applications (is it a breaking change?)
90
+
All user variations are subclasses of the `User` class.
109
91
110
-
There are tradeoffs to choosing any path. Attempt to identify them here.
92
+
The new user model adds the following new classes:
111
93
112
-
## Alternatives
94
+
- Member
95
+
- Abstract class
96
+
- AlumniMember
97
+
- An SSTAA member who studied in SST
98
+
- EmployeeMember
99
+
- An SSTAA member who has previously worked in SST, is working in SST, or previously studied in SST and is now working in SST
100
+
- Employee
101
+
- An employee of SST who is not an SSTAA member
102
+
- ServiceAccount
103
+
- A service account used by SSTAARs or the Guard House app
104
+
- SystemAdmin
105
+
- Root
113
106
114
-
What other designs have been considered? What is the impact of not doing this?
107
+
In the case of `AlumniMember` and `EmployeeMember`, although they both contain the same properties, they need to fulfill different requirements. For example, `EmployeeMember` is restricted to the Associate membership type.
115
108
116
-
## Adoption strategy
109
+
Implemented code is available ata<https://github.com/sstalumniassociation/api/tree/feat/users/Api/Entities>.
117
110
118
-
If we implement this proposal, how will existing React developers adopt it? Is
119
-
this a breaking change? Can we write a codemod? Should we coordinate with
120
-
other projects or libraries?
111
+
## Drawbacks
112
+
113
+
- It is a breaking change and non-backwards compatible. This means it will require downstream updates to all SSTAA apps, including the SSTAARs iPad companion app.
114
+
- Although it allowes greater flexibility in the use cases that SSTAA can handle, it also increases the complexity of the platform. I would argue that the complexity is a necessary evil in this specific case.
121
115
122
-
## How we teach this
116
+
## Alternatives
123
117
124
-
What names and terminology work best for these concepts and why? How is this
125
-
idea best presented? As a continuation of existing React patterns?
118
+
No alternatives were considered yet.
119
+
120
+
## Adoption strategy
126
121
127
-
Would the acceptance of this proposal mean the React documentation must be
128
-
re-organized or altered? Does it change how React is taught to new developers
129
-
at any level?
122
+
This will be adopted as part of the new v1 API rollout. SDKs will be provided which support both gRPC and REST.
130
123
131
-
How should this feature be taught to existing React developers?
124
+
Since this change is not backwards compatible, it will require updates.
132
125
133
126
## Unresolved questions
134
127
135
-
Optional, but suggested for first drafts. What parts of the design are still
136
-
TBD?
128
+
- Have not fully thought through the fields required for the various users, ond the other information that should be stored.
129
+
- How will this integrate with events / bookings in the future? Since they are currently available at the user model, it means a service account could technically make a booking. Should the relationship be changed?
0 commit comments