Implement the /api/positions endpoint. See the old pyceo code for the general idea. Basically you need to add/remove/modify the 'position' attribute for the execs' LDAP records.
The endpoint should accept some sort of JSON body which specifies the positions of all execs (i.e. no partial update). An error should be returned if the important positions are not filled (pres, VP, treasurer, sysadmin).
It should also subscribe new execs to the exec mailing list, and unsubscribe departing execs.
Since this endpoint is doing multiple things in one request, you should use the transaction model (see the AddMemberTransaction for an example).
Implement the /api/positions endpoint. See the old pyceo code for the general idea. Basically you need to add/remove/modify the 'position' attribute for the execs' LDAP records.
The endpoint should accept some sort of JSON body which specifies the positions of **all** execs (i.e. no partial update). An error should be returned if the important positions are not filled (pres, VP, treasurer, sysadmin).
It should also subscribe new execs to the exec mailing list, and unsubscribe departing execs.
Since this endpoint is doing multiple things in one request, you should use the transaction model (see the AddMemberTransaction for an example).
I'll use this request body as example for implementation:
```json
{
"positions": {
"r345liu": ["treasurer", "sysadmin"],
"merenber": ["pres", "vp"]
}
}
```
I think it makes more sense to use the positions as the keys, e.g.
{"president":"k4tu","vice-president":"g2le",...}
The TUI for ceo will look like this, so it makes more sense for the API to follow suit.
I think it makes more sense to use the positions as the keys, e.g.
```json
{
"president": "k4tu",
"vice-president": "g2le",
...
}
```
The TUI for ceo will look like this, so it makes more sense for the API to follow suit.
Implement the /api/positions endpoint. See the old pyceo code for the general idea. Basically you need to add/remove/modify the 'position' attribute for the execs' LDAP records.
The endpoint should accept some sort of JSON body which specifies the positions of all execs (i.e. no partial update). An error should be returned if the important positions are not filled (pres, VP, treasurer, sysadmin).
It should also subscribe new execs to the exec mailing list, and unsubscribe departing execs.
Since this endpoint is doing multiple things in one request, you should use the transaction model (see the AddMemberTransaction for an example).
I'll use this request body as example for implementation:
I think it makes more sense to use the positions as the keys, e.g.
The TUI for ceo will look like this, so it makes more sense for the API to follow suit.