Display deprecation notices on the API tokens config page and deprecation status in the resource.

Review Request #12631 — Created Sept. 26, 2022 and submitted

Information

Review Board
release-5.0.x

Reviewers

This change adds a deprecated field to the API token web API resource. This
is a bool showing whether the token was generated by a deprecated token
generator. We also now display a notice on the API tokens config page if a
token is deprecated. The notice encourages the user to delete the deprecated
token and generate a new one.

  • Made some GET requests to the /api-tokens/ list endpoint and saw that the
    deprecated field was included in the token resources.
  • Created some deprecated tokens and made sure they behave correctly and
    appear with the notice in the API tokens page.
  • Ran JS unit tests.
  • Ran reviewboard/webapi/tests/test_api_token.py
Summary ID
Handle token deprecation.
1e3856ec489ae198302d4477260a560313a60f6f

Description From Last Updated

The summary's a bit too long. Should fit under 80 chars.

chipx86chipx86

Summary of the change is still too long.

daviddavid

I like it, but I'm also thinking that we should be consistent with the way we present both deprecation and …

chipx86chipx86

Maybe a good time to just make this more manageable by having it a list with item per line.

chipx86chipx86

How about "This token uses a deprecated format"?

daviddavid

We try to only use colors stored in #rb-ns-ui.colors[@constant-name] these days, as that helps us keep the UI more consistent. …

chipx86chipx86

Let's keep each item in the list in its own line, like: syncAttrs: [ '...', '...', ... '...', ] That …

chipx86chipx86

For these new-style multi-line function definitions where we use typing, the final argument should always have a trailing comma.

chipx86chipx86

Same here.

chipx86chipx86

Same here.

chipx86chipx86

Same here.

chipx86chipx86

Same here.

chipx86chipx86

Same here.

chipx86chipx86
chipx86
  1. 
      
  2. The summary's a bit too long. Should fit under 80 chars.

  3. I like it, but I'm also thinking that we should be consistent with the way we present both deprecation and expiration notices.

    This has the advantage of being very visible, but has the same rough height as a token entry. Almost makes it look like it's replaced a token.

    Maybe we should just make this a red inline like the expired notice, under the hash.

    1. Ah yeah I see what you mean about it being the same size as a token entry. The inline sounds good, but I'm thinking of giving it a yellowish colour so that it has more of a warning vibe since deprecated tokens can still be used whereas invalidated/expired tokens can't.

  4. Maybe a good time to just make this more manageable by having it a list with item per line.

  5. 
      
maubin
david
  1. 
      
  2. Summary of the change is still too long.

  3. How about "This token uses a deprecated format"?

  4. 
      
maubin
david
  1. Ship It!
  2. 
      
maubin
chipx86
  1. 
      
  2. We try to only use colors stored in #rb-ns-ui.colors[@constant-name] these days, as that helps us keep the UI more consistent. However, there isn't one for this, and we may not be able to really have one without using brown (which doesn't convey the same thing).

    The reason is that orange colors contrast poorly with white backgrounds, and in fact will almost surely fail WCAG (Web Content Accessibility Guidelines). Browsers can help check for this, but this tool is also useful:

    https://webaim.org/resources/contrastchecker/

    If you plug the hex code for this RGB (#D1AE00) into the tool, you'll see it fails validation.

    Rather than go with a text color here, I think a better approach is to use black, but prefix with a warning icon. So, same general idea as the alert you had before, but without all the chrome of the alert. Just the icon and text.

    You can do that with the same approach that the alert styles do, with a :before {} for this rule that uses content: @fa-var-warning.

  3. reviewboard/static/rb/js/accountPrefsPage/views/apiTokensView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     
     
     
     
     

    Let's keep each item in the list in its own line, like:

    syncAttrs: [
        '...',
        '...',
        ...
        '...',
    ]
    

    That keeps this maintainable as we add to it, and ensures we don't have to change the syncAttrs line if adding something before deprecated (which could cascade into changes for a couple of lines in the diff viewer) and that we won't have to change the valid line if adding something after it (since it'll end in a trailing comma like all others, letting us easily append at will).

  4. For these new-style multi-line function definitions where we use typing, the final argument should always have a trailing comma.

  5. Same here.

  6. Same here.

  7. Same here.

  8. Same here.

  9. Same here.

  10. 
      
maubin
chipx86
  1. Ship It!
  2. 
      
maubin
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-5.0.x (b39d4a9)
Loading...