Skip to content
This repository has been archived by the owner on May 24, 2024. It is now read-only.

Gantt chart tasks come with an undesired border - would prefer an option to disable it to satisfy client #140

Open
1 of 8 tasks
Matthematic opened this issue Jun 1, 2021 · 8 comments

Comments

@Matthematic
Copy link

Matthematic commented Jun 1, 2021

Feature Request

Description

A client that is testing our app has complained of borders showing up between a list of rapid, short events that they created with an infusion pump. They expect these separate infusions to appear as one long bar, but the problem is that carbon adds a border somewhere that shows separation lines. We would be grateful if this border could be removed via a config option.

image

Graphs affected

  • Bar graph
  • Bubble graph
  • Gantt chart
  • Line graph
  • Paired result
  • Pie chart
  • Scatter plot
  • Timeline

Steps to Reproduce

  1. Create a Gantt graph
  2. Render a series of contiguous tasks with no gap between them
  3. Observe borders

Link to CodeSandbox

https://codesandbox.io/s/cool-architecture-3yh3v?file=/src/data.js

Additional Context / Screenshots

Expected Behavior

We expect the borders to support an option to remove them so that they dont display

Possible Solution

Environment

  • Component Name and Version:
  • Browser Name and Version:
  • Node/npm Version: [e.g. Node 8/npm 5]
  • Webpack Version:
  • Operating System and version (desktop or mobile):

@ Mentions

@lj017464
Copy link

lj017464 commented Jun 28, 2021

@mallorymcc or @ryanthemanuel looking for an update on this issue, so that we can update the client. We have a reassembly correction JIRA logged on our end https://jira2.cerner.com/browse/CCDEV-16545 that we are tracking on.

CHLD_MA, our validation partner has raised this as a go-live issue.

@lj017464
Copy link

lj017464 commented Jul 7, 2021

Hi @ryanthemanuel & @mraplumb, can you please update us on when this is planned for?

@lj017464
Copy link

lj017464 commented Jul 20, 2021

Hi @ryanthemanuel and @mraplumb -- I'm being asked by the engagement owner for an update on this particular issue. I told them we would regularly follow-up on this. We are trying to better understand where this falls backlog or sprint wise.

@sdadn sdadn removed the Up Next - KC Issues that are ready to pull into an iteration for the KC team label Aug 6, 2021
@lj017464
Copy link

@sdadn Is there a Sprint that this is assigned to? Also, is there a JIRA that we can track on? As of 7/29, Andy indicated it was being planned for, for an upcoming sprint.

@sdadn
Copy link
Contributor

sdadn commented Aug 17, 2021

@lj017464 @Matthematic , it seems like you want the final result to be something like this:

image

How important is maintaining the uniqueness of each individual event? Do you need each of the individual events to still be clickable and show its corresponding data? Can you elaborate on the use case requiring the separation lines to be removed?

@lj017464
Copy link

lj017464 commented Aug 17, 2021

@sdadn This UI is representing a continuous infusion order, so the clinician is expecting the UI to reflect that the bag is running continuously when they are documenting hourly infuse events, where the time span captured is for the full hour: 10:00-10:59, 11:00-11:59, 12:00-12:59, etc.

These individuals events are not selectable for the order type that we are displaying them for. To view the details of the event, the user would click the Gantt row and see a breakdown of the events in our Activity slide panel.

For example:
image

Note: In the example above, I manually documented the starts and end times. Typically, documentation is signed from IView or the Infusion Documentation component where the start and end of volume encompass the full hour -- 10:00-10:59

@sdadn
Copy link
Contributor

sdadn commented Aug 19, 2021

@lj017464 how important is it to maintain the data for each of the individual events? E.g is it feasible to represent:

  • 7:00-7:59
  • 8:00-8:59
  • 9:00-9:59

as

  • 7:00-9:59 ?

@lj017464
Copy link

lj017464 commented Aug 19, 2021

@sdadn Each infuse administration would be viewed as its own event on drill-in, so we would not combine three different clinical events together as each one of those has its uniqueness from a documentation perspective.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants