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

UICAL-132: Calendar hours displaying on wrong day of week #318

Merged
merged 1 commit into from
Feb 21, 2021

Conversation

Dmitriy-Litvinenko
Copy link
Contributor

Description

  • Calendar hours displaying on wrong day of week

Stories

https://issues.folio.org/browse/UICAL-132

Screenshots

image
image

@id-jenkins
Copy link

yarn run v1.22.4
$ eslint .

/home/jenkins/workspace/folio-org_ui-calendar_PR-318/project/src/settings/OpenExceptionalForm/ExceptionWrapper.js
79:3 error Identifier 'UNSAFE_componentWillMount' is not in camel case camelcase

✖ 1 problem (1 error, 0 warnings)

info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

@sonarcloud
Copy link

sonarcloud bot commented Feb 17, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

100.0% 100.0% Coverage
0.0% 0.0% Duplication

Copy link
Member

@zburke zburke left a comment

Choose a reason for hiding this comment

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

Sorry, I'm at a total loss to understand what's going on here.

There is no description in this PR of why removing getEvents() resolves the problem. Frustratingly, there is also no description in the PR that added this code (#188) to describe how getEvents() was expected to resolve the problem in the first place.

AFAIK, the bug in react-big-calendar, identified when getEvents() was added, remains: it was closed because it was stale, not because it was fixed.

If their code hasn't changed, why is our workaround no longer necessary?

@Dmitriy-Litvinenko
Copy link
Contributor Author

Dmitriy-Litvinenko commented Feb 19, 2021

Sorry, I'm at a total loss to understand what's going on here.

There is no description in this PR of why removing getEvents() resolves the problem. Frustratingly, there is also no description in the PR that added this code (#188) to describe how getEvents() was expected to resolve the problem in the first place.

AFAIK, the bug in react-big-calendar, identified when getEvents() was added, remains: it was closed because it was stale, not because it was fixed.

If their code hasn't changed, why is our workaround no longer necessary?

@zburke
Hello,
I described below reason for remove getEvents().

  1. How you already say we don't have "description in the PR that added this code (UICAL-62: Add tests for OpenExceptionalPeriod. #188)".
  2. We have https://issues.folio.org/browse/UICAL-55 for apply UTC time zone for date/time controls.
  3. When we create event
    end: moment(start).add(i, 'days'), // start and end have the same value
    start: moment(start).add(i, 'days'), // start and end have the same value
    title: eventTitle, // string
  4. How you can see from screen below 1 - string 2 - don't have any "line with time" (for example 12:00 AM and etc)
    UICAL-132
  5. Workaround with getEvents() can't change title(string) and can't to impact on "line with time" because we don't have them.
  6. The current behavior in getEvents() results in an error described in https://issues.folio.org/browse/UICAL-132

@Dmitriy-Litvinenko Dmitriy-Litvinenko merged commit 17db7d0 into master Feb 21, 2021
@Dmitriy-Litvinenko Dmitriy-Litvinenko deleted the UICAL-132 branch February 21, 2021 21:23
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.

5 participants