Naming of the inbound Github repo can not inclued '.' symbol

Wiredcraft / fullpm

Kanban board for GitHub issues

https://wiredcraft.com/products/fullpm

1 stars 3 forks source link

Naming of the inbound Github repo can not inclued '.' symbol #36

Closed ChopperLee2011 closed 7 years ago

ChopperLee2011 commented 8 years ago

the backend uses Github repo name as one CouchDB database name, so follow CouchDB naming limitation

all lowercase letters (a-z), digits (0-9), or any of the _$()+-/

we can not create the cache DB which include '.'

so here is the solution base on the design for now:

ignore the '.' symbol, so the repo a.b and ab mean the same thing in our system. this will make customer confuse if he/she really have these two Github repos, but only can inbound one in our app.
change the . symbol to legal symbol to CouchDB, like '$$' then, a.b and a$$b mean the same thing in our system, the good part is we can choose one symbol which we conside customer would not use in their Github repo, the bad part is we need to do parse in both backend and frontend.
rejected to inbound Github repo which inclued '.' symbol, easy but also confusing.

EcutDavid commented 8 years ago

I suggest using your second recommendation, and we can create a lib dir in repo's root, and provide methods like parseRepo, repoNameEncoding or repoNameDecoding and we can share the method both front-end and back-end.

JuhaS commented 8 years ago

I had these comments in slack:

using the numerical repo-id would have benefits, such as managing repo renames, etc. This would require to manage the repo-name to id mapping elsewhere.
(slightly related) I think we'll need a data model for an organization or a board, so we can attach information to them, to my current understanding we don't have this now. For example I'd like if the data structure doesn't limit from having a per-user/custom boards in the future.

hunvreus commented 8 years ago

As @JuhaS mentioned, we could simply use the repo-id; it won't break and will support renaming.

JuhaS commented 8 years ago

Actually I would probably recommend not tying the boards to the repositories directly at all. I mean we would have a board-id for each board that identifies them and maybe inside that define board-type and some github related fields. This would give us more flexibility in the future and decouple the board mechanics from anything github related. For example making it easier to create custom boards where board is tied to many repos, or personal boards where board is tied to user.