Added initial Todo list/notes
Signed-off-by: Ethan Wellenreiter <ewellenreiter@gmail.com>
This commit is contained in:
parent
d1a267eb44
commit
7e813fa3f8
39
TODO.md
Normal file
39
TODO.md
Normal file
@ -0,0 +1,39 @@
|
||||
1. Figure out the different structures and objects. receipts. receipt images. groups, so on.
|
||||
2. Complete the api design
|
||||
3. figure out the inbetween logic. especially for stuff that could include a transaction
|
||||
4. transactional stuff maybe should be brought up to a higher level and we can just allow a transaction type thing to be passed through them
|
||||
5. consider ignoring nosql as being an option for the system for anything other than storing receipts data maybe
|
||||
|
||||
|
||||
|
||||
ReceiptImage -> metadata, link or whatever is needed for S3 stuff
|
||||
Receipt -> Many Receipt Images, receipt data, receipt metadata
|
||||
|
||||
|
||||
Want to accomodate a single user. they can then group receipts. groups can be personal but also organization? should be able to filter which receipts are shown by personal vs organization groups? maybe by owned groups?
|
||||
a group can also have certain people who are allowed to add other people, but also adding receipts vs just viewing receipts vs only adding and seeing their own stuff? [for this, there can be roles which are strict and placed into the roles table but also stored in the groupMembership table]
|
||||
|
||||
try and implement sso? it could probably work...
|
||||
|
||||
organizations can have groups themselves. they can be set to own the groups. an organization should have one owner and then admins. admins can do everything but stuff integral to the organization like deleting it, changing the name, that stuff.
|
||||
|
||||
anyone can make an organization and add people as admins.
|
||||
|
||||
- a user does not have to be part of an organization.
|
||||
- an organization must have an owner
|
||||
- a group must have an owner
|
||||
- a receipt must be part of a group (if anything, it's the default group for the user, which is hidden)
|
||||
- a group can have admins
|
||||
- an admin cannot delete the group. a "super admin" (an organization admin) can though. super admins are at the same level as owners
|
||||
- an organization can have groups
|
||||
- an organization itself has no ability to add receipts
|
||||
- a user must add a group under an organization to begin adding receipts
|
||||
- an organization is really just a way to have multiple people acting like owners of a group and they get added automatically.
|
||||
- maybe an organization can also group groups? so like subsections or suborganizations? call them sections. sections can nest
|
||||
- a section or organization directly can have groups.
|
||||
- alternatively, we can work with the section nesting and say that an organization by default has a section covering the whole thing, kind of like a users default group.
|
||||
- a receipt cannot be part of multiple groups at once
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user