Polar
Allow admins to manually upgrade an existing license key’s entitlement / benefit tier #10044
Replies: 1 comment
-
Basic writing and formatting syntaxCreate sophisticated formatting for your prose and code on GitHub with simple syntax. HeadingsTo create a heading, add one to six # symbols before your heading text. The number of # you use will determine the hierarchy level and typeface size of the heading. # A first-level heading
## A second-level heading
### A third-level heading
When you use two or more headings, GitHub automatically generates a table of contents that you can access by clicking the "Outline" menu icon within the file header. Each heading title is listed in the table of contents and you can click a title to navigate to the selected section.
Styling textYou can indicate emphasis with bold, italic, strikethrough, subscript, or superscript text in comment fields and
Quoting textYou can quote text with a >. Text that is not a quote
> Text that is a quoteQuoted text is indented with a vertical line on the left and displayed using gray type.
Note When viewing a conversation, you can automatically quote text in a comment by highlighting the text, then typing R. You can quote an entire comment by clicking , then Quote reply. For more information about keyboard shortcuts, see Keyboard shortcuts. Quoting codeYou can call out code or a command within a sentence with single backticks. The text within the backticks will not be formatted. You can also press the Command+E (Mac) or Ctrl+E (Windows/Linux) keyboard shortcut to insert the backticks for a code block within a line of Markdown. Use `git status` to list all new or modified files that haven't yet been committed.
To format code or text into its own distinct block, use triple backticks. Some basic Git commands are:
```
git status
git add
git commit
```
For more information, see Creating and highlighting code blocks. If you are frequently editing code snippets and tables, you may benefit from enabling a fixed-width font in all comment fields on GitHub. For more information, see About writing and formatting on GitHub. Supported color modelsIn issues, pull requests, and discussions, you can call out colors within a sentence by using backticks. A supported color model within backticks will display a visualization of the color. The background color is `#ffffff` for light mode and `#000000` for dark mode.
Here are the currently supported color models.
Note
LinksYou can create an inline link by wrapping link text in brackets You can also create a Markdown hyperlink by highlighting the text and using the keyboard shortcut Command+V. If you'd like to replace the text with the link, use the keyboard shortcut Command+Shift+V.
Note GitHub automatically creates links when valid URLs are written in a comment. For more information, see Autolinked references and URLs. Section linksYou can link directly to any section that has a heading. To view the automatically generated anchor in a rendered file, hover over the section heading to expose the icon and click the icon to display the anchor in your browser.
If you need to determine the anchor for a heading in a file you are editing, you can use the following basic rules:
For more detailed information on the requirements of URI fragments, see RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, Section 3.5. The code block below demonstrates the basic rules used to generate anchors from headings in rendered content. # Example headings
## Sample Section
## This'll be a _Helpful_ Section About the Greek Letter Θ!
A heading containing characters not allowed in fragments, UTF-8 characters, two consecutive spaces between the first and second words, and formatting.
## This heading is not unique in the file
TEXT 1
## This heading is not unique in the file
TEXT 2
# Links to the example headings above
Link to the sample section: [Link Text](#sample-section).
Link to the helpful section: [Link Text](#thisll-be-a-helpful-section-about-the-greek-letter-Θ).
Link to the first non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file).
Link to the second non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file-1).Note If you edit a heading, or if you change the order of headings with "identical" anchors, you will also need to update any links to those headings as the anchors will change. Relative linksYou can define relative links and image paths in your rendered files to help readers navigate to other files in your repository. A relative link is a link that is relative to the current file. For example, if you have a README file in root of your repository, and you have another file in docs/CONTRIBUTING.md, the relative link to CONTRIBUTING.md in your README might look like this: GitHub will automatically transform your relative link or image path based on whatever branch you're currently on, so that the link or path always works. The path of the link will be relative to the current file. Links starting with Your link text should be on a single line. The example below will not work. [Contribution
guidelines for this project](docs/CONTRIBUTING.md)Relative links are easier for users who clone your repository. Absolute links may not work in clones of your repository - we recommend using relative links to refer to other files within your repository. Custom anchorsYou can use standard HTML anchor tags ( Note Custom anchors will not be included in the document outline/Table of Contents. You can link to a custom anchor using the value of the For example: # Section Heading
Some body text of this section.
<a name="my-custom-anchor-point"></a>
Some text I want to provide a direct link to, but which doesn't have its own heading.
(… more content…)
[A link to that custom anchor](#my-custom-anchor-point)Tip Custom anchors are not considered by the automatic naming and numbering behavior of automatic heading links. Line breaksIf you're writing in issues, pull requests, or discussions in a repository, GitHub will render a line break automatically: This example
Will span two linesHowever, if you are writing in an .md file, the example above would render on one line without a line break. To create a line break in an .md file, you will need to include one of the following:
If you leave a blank line between two lines, both .md files and Markdown in issues, pull requests, and discussions will render the two lines separated by the blank line: This example
Will have a blank line separating both linesImagesYou can display an image by adding ! and wrapping the alt text in
GitHub supports embedding images into your issues, pull requests, discussions, comments and Note When you want to display an image that is in your repository, use relative links instead of absolute links. Here are some examples for using relative links to display an image.
Note The last two relative links in the table above will work for images in a private repository only if the viewer has at least read access to the private repository that contains these images. For more information, see Relative Links. The Picture elementThe ListsYou can make an unordered list by preceding one or more lines of text with -, *, or +. - George Washington
* John Adams
+ Thomas Jefferson
To order your list, precede each line with a number. 1. James Madison
2. James Monroe
3. John Quincy Adams
Nested ListsYou can create a nested list by indenting one or more list items below another item. To create a nested list using the web editor on GitHub or a text editor that uses a monospaced font, like Visual Studio Code, you can align your list visually. Type space characters in front of your nested list item until the list marker character (- or *) lies directly below the first character of the text in the item above it. 1. First list item
- First nested list item
- Second nested list itemNote In the web-based editor, you can indent or dedent one or more lines of text by first highlighting the desired lines and then using Tab or Shift+Tab</ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Feature request
Right now, when a customer upgrades from one plan to another (for example, Plus -> Pro), there does not appear to be a way for an admin to manually upgrade the entitlement/benefit tier of an existing license key.
This makes some common workflows difficult:
I’d like admins to be able to manually upgrade (or change) the effective entitlement of an existing license key from the Polar dashboard and API.
For example:
This would be especially useful for software businesses with tiered licenses such as:
Is this something Polar is considering on the roadmap?
Beta Was this translation helpful? Give feedback.
All reactions