-
Notifications
You must be signed in to change notification settings - Fork 3
Upcoming features
Eric Walker edited this page Sep 8, 2019
·
26 revisions
Following are some notes on possible features to be built out at some point.
Allow people to log in with their Google accounts. Depends on #32.
- Move the GitHub-specific fields on the users table into a separate relation.
- Add a new table to hold Google-specific fields.
- Add a "Log in with Google" button to the sign-in page.
- After clicking on the login button, the user is presented with the Google permissions page and accepts the permissions. If everything works, the user is then redirected back to Digraph.
- Extend the registration workflow to have the user choose a "login" name to be used in url paths. (It's not really a login name, since the user doesn't provide it when logging in, but this is the name used by other services, so we'll use it here as well.)
- The potential login name provided by the user during this second step is cross-checked with GitHub login names and is considered invalid if an identical GitHub login name exists. The input field forces the user to choose a GitHub-like login name by disallowing certain letters and combinations of letters.
- Once the new user has chosen a valid login name, account registration will be marked as complete, and the next time the user logs in, they will go straight to the landing page.
The cross-check against GitHub is needed to prevent issues from arising when a GitHub user with the same account name later attempts to log in. Things should just work for GitHub users without their having to select a different login name.
Save the user the trouble of tagging some links with frequently used topics that are easy to infer, such as Articles in the New York Times. Provide a view or set of views that can be configured by users to automatically apply tags using different patterns and selection criteria. The matching rules will be specific to a repo.
- Add a screen for settings on a repo that will eventually contain a description that can be edited, links to permissions and a red delete button.
- Add metadata fields to the repo table, or add a table of repo metadata, to hold things like the description.
- Add a link for getting to the settings for a repo — perhaps a gear icon somewhere.
- Only show the screen if the person has permissions to configure the settings on the repo.
- Add a section for tagging rules, with a list of rules that can be edited inline.
- Add a table to hold rules with a reference to the repo for the rule.
- Add a table to hold patterns for rules with a reference to the table of rules.
- Add a table to hold topics for rules with a reference to the table of rules.
- Add a service to upsert a rule.
- Add a service to delete a rule.
- Add a mutation to upsert a rule.
- Add a mutation to delete a rule.
- Add a form for editing a rule. The form has one (or more?) patterns that can be used to match against a url, a title, and (at some point) the contents of a document. The patterns can be a simple string match or a regex. The form also has an element to choose a tag to apply (or a multi-select of tags to apply?).
Questions:
- Should a rule apply only a single topic, or should it be possible to configure a rule to apply multiple topics? Restricting a rule to a single topic keeps things simple. Allowing a rule to apply several topics might be more convenient. Perhaps the UI can start out allowing only a single topic, while the tables are modeled to potentially allow additional topics per rule in the future.