0
0
mirror of https://github.com/naturalcrit/homebrewery.git synced 2026-03-28 05:48:16 +00:00

Updated Folders etc (markdown)

ericscheid
2023-12-04 15:30:16 +11:00
parent c50ab402ae
commit c5b3264c6c

@@ -26,13 +26,12 @@ The MVP should include:
"CRUD" features: create folders, delete folders, update name and contents, and be able to read the contents. "CRUD" features: create folders, delete folders, update name and contents, and be able to read the contents.
Author-specific Author-specific
Opening a link for a non-existant folder should trigger a 404 - opening a link for a non-existant folder should trigger a 404
a brew should be able to be in multiple folders at once - a brew should be able to be in multiple folders at once
folders can have subfolders of their own - folders can have subfolders of their own
no duplicate names for folders inside the same account - no duplicate names for folders inside the same account
Folder should appear in the brew title inside the share and edit pages("Examples: how to make tables") - folder should appear in the brew title inside the share and edit pages("Examples: how to make tables")
Folders should appear before any brew in the user page - folders should appear before any brew in the user page
A URI/link should be `/user/:userId/:folderName` A URI/link should be `/user/:userId/:folderName`
@@ -42,19 +41,23 @@ A URI/link should be `/user/:userId/:folderName`
Folders exist as entities in their own table/collection. Folders exist as entities in their own table/collection.
Each folder is owned by one owner, and it only appears in the context of _their_ userpage.
Multiple brews can be assigned to a folder by listing the `brew.shareID` in the folder entity. (This is distinct and different from a model where the association is achieved via an attribute on the brew entity). Multiple brews can be assigned to a folder by listing the `brew.shareID` in the folder entity. (This is distinct and different from a model where the association is achieved via an attribute on the brew entity).
Sub-folders are linked via a list of sub-folderIds, in the same manner as to how brews are linked.
### Data structure ### Minimal Data structure
- `__Id` (mongo specific ID field, exists wether we create it or not) - `__Id` (mongo specific ID field, exists wether we create it or not)
- `folderId` (nanoid, required, auto) - `folderId` (nanoid, required, auto)
- `folderName` (to use in the URL) (string, required) - `folderName` (to use in the URL) (string, required)
- `owner` (can be multiple) - `owner` (can be multiple?)
- `brewIds`(shareId) - `brewIds`(shareId)
- `createdAt` - `createdAt`
- `UpdatedAt` - `UpdatedAt`
https://gitter.ems.host/_matrix/media/v3/download/gitter.im/d336df8b6302961385db01f93e95f301c6cde3aa #### More substantial data structure
![image](https://github.com/naturalcrit/homebrewery/assets/2605467/90fa8be0-6728-46f9-a1e1-2d09975e292f)
@@ -62,7 +65,7 @@ These folders should be displayed in the user page of the author of such folder
So all unpublished files will still be invisible to unauthored accounts<!--although if you are an author you still can't see an unpublished brew, that needs a fix -->, even if they are inside a publicly viewable folder.<!--we could make it so that any folder without any published brew is invisible? --> So all unpublished files will still be invisible to unauthored accounts<!--although if you are an author you still can't see an unpublished brew, that needs a fix -->, even if they are inside a publicly viewable folder.<!--we could make it so that any folder without any published brew is invisible? -->
"Yes, so the "my campaign" folder can contain a published "magic ring" document that the players can see (because they have attained said ring) and also private "magic sword" document because players have not attained it." > "Yes, so the "my campaign" folder can contain a published "magic ring" document that the players can see (because they have attained said ring) and also private "magic sword" document because players have not attained it."
## Optimal Final Product ## Optimal Final Product