Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

THREESCALE-10245: access tokens expiration UI #3943

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

jlledom
Copy link
Contributor

@jlledom jlledom commented Nov 13, 2024

What this PR does / why we need it:

After we merged #3939 now we want to update the Access Tokens screens to add a new field for the expiration date. For this, I created a new React component based on what Github does:

  • A select input with the next options:
    • Expires in 7 days
    • In 30 days
    • In 60 days
    • In 90 days
    • Custom date
      • A calendar appears to select the desired date
    • No expiration
      • An warn is shown to advise the user to set an expiration date for security reasons

Which issue(s) this PR fixes

THREESCALE-10245

Verification steps

Just set the an expiration date when creating a token and verify the data is correctly stored in DB and is properly shown in #index and #edit screens

Screenshots

image

image

image

@jlledom jlledom requested a review from lvillen November 13, 2024 15:33
@jlledom jlledom self-assigned this Nov 13, 2024
@jlledom jlledom changed the base branch from master to THREESCALE-10245-expire-access-tokens November 13, 2024 15:33
@jlledom jlledom changed the title Threescale 10245 access tokens UI THREESCALE-10245: access tokens expiration UI Nov 13, 2024
@jlledom jlledom force-pushed the THREESCALE-10245-expire-access-tokens branch from 058be50 to 54db7d7 Compare November 26, 2024 08:58
Base automatically changed from THREESCALE-10245-expire-access-tokens to master November 26, 2024 09:11
@jlledom jlledom force-pushed the THREESCALE-10245-access-tokens-UI branch from c9d2ba3 to 995530a Compare November 26, 2024 11:15
@jlledom jlledom marked this pull request as ready for review November 26, 2024 11:37
@mayorova
Copy link
Contributor

mayorova commented Dec 3, 2024

Great job @jlledom ! 🏆
I'm still reviewing the implementation, but a couple of comments so far:

  1. The selected date in the hint on the form is a bit confusing...

Screenshot from 2024-12-03 16-56-09

Depending if it's US or not, the date can be interpreted differently.

I think the following presentation as it shows on the different screen is better.
Screenshot from 2024-12-03 16-55-37

Also, I think it would be nice to show the expiration date on the table listing all tokens...

Comment on lines 58 to 64
if (fieldDate) {
value = fieldDate.toISOString().replace(msExp, 'Z')
} else if (selectedItem.id === 5 ) {
value = pickedDate.toISOString().replace(msExp, 'Z')
}

return value
Copy link
Contributor

@mayorova mayorova Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the suggestion, because noticed that it's not just "if-else", but "if - else if", and value can be empty at the return.

Maybe we can accept both formats on the backend by using DateTime.parse? It seems to work both with milliseconds and no milliseconds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll explore this possibility, it might work

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlledom
Copy link
Contributor Author

jlledom commented Dec 4, 2024

Ideally, this provider setting should be the one source of truth for time zone and the react component should use that time zone instead of the browser's one. I was trying to fix it but I gave up, I don't remember why, but I could give it a try again because it's generating some confusion when there's difference between provider and browser timezones.

I couldn't do it. Basically I though on two approaches:

  1. Passing the provider time zone to the Patternfly calendar component
  2. Translating whatever datetime the client sends to provider timezone

Both failed. 1 can't be done because the Patternfly react component doesn't accept ant time zone, it will always use the OS timezone.
2 can't be done because at the moment of the value assignment (calling expires_at=) the owner attribute is nil, so we can't access the provider time zone.

Also, I think it would be nice to show the expiration date on the table listing all tokens...

Done 88badaf

<span className="pf-c-form-control-expiration-hint">{fieldHint}</span>
</FormGroup>
<input id={id} name={id} type="hidden" value={dateValue} />
{selectedItem.id === 5 && (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love these synthetic ids on the options list. It's a bit hard to understand why this is checked for equality with 5.

Some alternative ideas I had:

  • use a string instead of the numeric ID for an easier interpretation, e.g.
  { id: '7', name: '7 days', period: 7 },
  { id: '30', name: '30 days', period: 30 },
  { id: 'custom', name: 'Custom...', period: 0 },
  { id: 'no-exp', name: 'No expiration', period: 0 }

or something like that.

Or even remove the id, and reuse period, and have for example period: 0 for "no expiration", and period: -1 for custom. This way there are less values that we need to care about.

I also suggest to use label rather than name, as it is used for the field label in FormSelectOption, so we'll have something like

 <FormSelectOption
    key={item.period}
    label={item.label}
    value={item.period}
  />

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use a string instead of the numeric ID for an easier interpretation, e.g.

Done fda4ff2

Or even remove the id, and reuse period, and have for example period: 0 for "no expiration", and period: -1 for custom. This way there are less values that we need to care about.

I didn't do this because I find this as confusing as the previous code.

I also suggest to use label rather than name, as it is used for the field label in FormSelectOption, so we'll have something like

Done 14b083d

)}
{dateValue === '' && (
<>
<br />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this break here, but I couldn't find an easy way to add some top margin, so that's OK...

I was looking at https://pf4.patternfly.org/utilities/spacing/, and was hoping that adding className="pf-u-mt-md" would help, but it didn't 😬 I think that probably the CSS containing this class is not being loaded... not sure, but I didn't investigate further.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, now I think the parenthesis () are not needed, but well, not important.

@jlledom
Copy link
Contributor Author

jlledom commented Dec 5, 2024

From #3951:

Using helper text (under the select) instead of the custom span element to the right (which dos not look very Patternfly-y). The drawback is that when the select is expanded, the value is not seen, but I think it doesn't matter.

588b314

Changing the formatting of the "current value". Not sure it's a nice one (probably too long), but I think it's clear, and it also includes timestamp (but not sure if needed)

I didn't do this one because I think the current format is clear enough and it's formatted in client's time zone. Not sure if using UTC instead would make things clearer, as UTC time can belong to a different day to the client time zone.

When the date is selected via picker, the selected value is also shown now.

587a618

The default value when using "Custom..." is set to tomorrow
The past dates are not pickable in the date picker.

I agree on these two, but I didn't applied them because they make tests much more difficult. Check pickDate on the test suite.

@mayorova
Copy link
Contributor

mayorova commented Dec 9, 2024

I agree on these two, but I didn't applied them because they make tests much more difficult. Check pickDate on the test suite.

Ooh, well, that's sad, because I think they are very useful, especially not being able to pick later dates - because it doesn't make sense.

@mayorova
Copy link
Contributor

mayorova commented Dec 9, 2024

I didn't do this one because I think the current format is clear enough and it's formatted in client's time zone. Not sure if using UTC instead would make things clearer, as UTC time can belong to a different day to the client time zone.

Hm, well, I think it's confusing... I don't know where the locale setting for date.toLocaleDateString() is coming from... I've tried to change the language in my Chrome to non-US English, and I keep seeing 12/9/2024 for today. To me it's very confusing.

I'd prefer at least 9 Dec, 2024 or December 9, 2024 like on some other screens. And I still think that adding time could also be useful, because the actual expiry date does include time also, so for the customer it could be useful to know whether the token will expire at 00:01 or 23:59 of the same date.

@jlledom
Copy link
Contributor Author

jlledom commented Dec 12, 2024

Hm, well, I think it's confusing... I don't know where the locale setting for date.toLocaleDateString() is coming from...

I'd say it comes from the OS.

I'd prefer at least 9 Dec, 2024 or December 9, 2024 like on some other screens.

Which screens? maybe those screens take the locale from the provider settings.

@jlledom
Copy link
Contributor Author

jlledom commented Dec 12, 2024

I'd prefer at least 9 Dec, 2024 or December 9, 2024 like on some other screens.

Which screens? maybe those screens take the locale from the provider settings.

I correct myself, only the timezone can be configured for the provider, locale is always the same in porta for everybody. However, we don't use a single date format in all screens.

I think I'm gonna implement one of your suggestions.

Add a warning when the time zone differs from the provider's one
Jest complains about wrong syntax
¯\_(ツ)_/¯
@jlledom
Copy link
Contributor Author

jlledom commented Dec 12, 2024

@mayorova I updated the date format in the field hint.

Also, since I don't think we can, or should, fix the time zone mismatch problem, I added a warning to clarify which time will the token expire at.

image

The tooltip only appears when there's a timezone mismatch between the browser and the provider configuration.

@jlledom jlledom requested a review from mayorova December 12, 2024 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants