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

TASK-304 Another iteration over drawer for managing workers #279

Merged
merged 8 commits into from
Mar 20, 2021

Conversation

Qwebeck
Copy link
Member

@Qwebeck Qwebeck commented Mar 13, 2021

Poprawiłem drawer do edycji/dodawania pracownika w taki sposób, żeby działała konwersja godzin oraz dodałem komunikaty o błędach.

@Ehevi zerknij proszę na komunikaty które pojawiają się przy błędach i powiedz czy masz jakiś uwagi
@VVlovsky , @maciekb05 zerknijcie proszę od strony kodu

@cypress
Copy link

cypress bot commented Mar 14, 2021



Test summary

232 0 0 0Flakiness 0


Run details

Project NurseScheduling
Status Passed
Commit 7f56a2d
Started Mar 19, 2021 3:02 PM
Ended Mar 19, 2021 3:06 PM
Duration 03:47 💡
OS Linux Ubuntu - 20.04
Browser Custom chrome 88

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

src/components/namestable/use-worker-info.ts Show resolved Hide resolved
/>
<FormFieldErrorLabel
condition={!isTimeValid()}
message={`Ilość godzin powinna być mniejsza od ${maximumWorkHoursForMonth}`}
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

Liczba godzin. Godziny są policzalne 😝

/>
<FormFieldErrorLabel
condition={!isEmployementTimeValid(employementTime)}
message="Etat powinien być mniejszy lub równy jeden"
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

@Ehevi Ehevi left a comment

Choose a reason for hiding this comment

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

  • liczba godzin (skoro godziny liczymy, to są policzalne) 😛 ilość czasu (niepoliczalne)
  • zda RZ ały się nawet rozprawy sądowe dotyczące tego, co znaczy powinien w określonych dokumentach! Językowo powinien wyraża imperatyw trochę innego rodzaju niż musi i według niektórych interpretacji nie jest równie nakazujący. https://sjp.pl/powinien
    powinien
    Kategorycznie nie dopuszczamy etatu ≥ 1. To może Pracownik nie może być zatrudniony na więcej niż jeden etat?
  • "Nie zdefiniowano X" brzmi w tym przypadku naturalniej niż "X musi być zdefiniowane", ale wtedy tracimy podkreślenie wokół X. Może by je uwydatnić w jakiś sposób wizualny (np. boldem)?

@Qwebeck
Copy link
Member Author

Qwebeck commented Mar 14, 2021

Dzięki za szybkie review 👍
Poprawiłem wszystkie komunikaty o których pisałaś,
Co do tego:

"Nie zdefiniowano X" brzmi w tym przypadku naturalniej niż "X musi być zdefiniowane", ale wtedy tracimy podkreślenie wokół X. Może by je uwydatnić w jakiś sposób wizualny (np. boldem)?

to mi się wydaje, że raczej nie ma takiej potrzeby, ponieważ te komunikaty i tak pojawiają się w pod konkretnymi polami, więc i tak wiadomo o co chodzi

image

@Qwebeck Qwebeck requested review from prenc and Ehevi March 14, 2021 09:17
Comment on lines 49 to 62
{
condition: isWorkerWithSameNameExists(),
message: `Pracownik o imieniu ${workerName} już istnieje`,
},
{
condition: isWorkerNameEmpty(),
message: "Nie zdefiniowano imienia pracownika",
},
];

return (
<>
<Grid item xs={6}>
<Typography className={classes.label}>Imię i nazwisko</Typography>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Właściwie to nie wiem, czy użycie synekdochy (pars pro toto) w tym przypadku jest poprawne. Nie chodzi nam przecież o imię jako samo imię, tylko bardziej o jednoznaczny identyfikator pracownika. To chyba nie jest jakaś niedopuszczalna sytuacja, że w danym miejscu pracują dwie osoby o takich samych imionach.

Copy link
Member Author

Choose a reason for hiding this comment

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

Masz rację.
Ale nie wiem jak to zamienić: jedyne co przychodzi do głowy - Identyfikator pracownika, ale to brzmi słabo.
Natomiast ta sytuacja o której ty mówisz raczej jest rzadka.
Moim zdaniem lepiej zostać przy tym co jest teraz .
@prenc, co ty o tym myślisz?

Copy link
Contributor

Choose a reason for hiding this comment

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

Żeby być spójnym można by to nazwać nazwa pracownika (bo zawiera imię i nazwisko, ew. coś jeszcze), ale może to średnio brzmieć.

Co do tego co mówi Agata, to niewiele rozumiem, albo używasz pojęcie imienia wymiennie z nazwą pracownika. Już dopuszczamy kilku pracowników o tym samym imieniu i w teorii, również o tej samej nazwie (case ze zmianą typu umowy).

Copy link
Member Author

Choose a reason for hiding this comment

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

@Ehevi
Chyba poprawiłem synekdochy xd (jeśli chodziło o to nazwa pola - to Imię i nazwisko, a w komunikacie piszemy tylko o imieniu)

Co do tego, żeby zamienić Imię i nazwisko na coś innego, to tego już nie robiłem.
Myśle, że one i tak to zrozumieją w razie czego.

Copy link
Collaborator

Choose a reason for hiding this comment

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

To może Taki pracownik już istnieje? Skoro zakładamy, że będziemy ich jednoznacznie określać za pomocą imion i nazwisk (co nadal jest synekdochą).

Copy link
Contributor

Choose a reason for hiding this comment

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

@Ehevi

Co do tego co mówi Agata, to niewiele rozumiem, albo używasz pojęcie imienia wymiennie z nazwą pracownika. Już dopuszczamy kilku pracowników o tym samym imieniu i w teorii, również o tej samej nazwie (case ze zmianą typu umowy).

@Ehevi
Copy link
Collaborator

Ehevi commented Mar 14, 2021

te komunikaty i tak pojawiają się w pod konkretnymi polami

To może w takim przypadku wystarczyłoby Należy uzupełnić to pole?

@Qwebeck
Copy link
Member Author

Qwebeck commented Mar 14, 2021

te komunikaty i tak pojawiają się w pod konkretnymi polami

To może w takim przypadku wystarczyłoby Należy uzupełnić to pole?

Powiem szczerze, e mi bardziej się podoba aktualna wersja komunikatów.
Ale niech też ktoś inny się wypowie.
@prenc

@prenc prenc changed the title TASK-304 usable worker drawer TASK-304 Another iteration over drawer for managing workers Mar 14, 2021
@prenc
Copy link
Contributor

prenc commented Mar 14, 2021

  • zdażały
    @Ehevi
    zdarzały? :P

@prenc
Copy link
Contributor

prenc commented Mar 14, 2021

te komunikaty i tak pojawiają się w pod konkretnymi polami

To może w takim przypadku wystarczyłoby Należy uzupełnić to pole?

Powiem szczerze, e mi bardziej się podoba aktualna wersja komunikatów.
Ale niech też ktoś inny się wypowie.
@prenc

Byłbym raczej za czymś typu, wybierz typ umowy, wpisz nazwę pracownika, wybierz wymiar etatu

@Qwebeck Qwebeck force-pushed the TASK-304-work-hour-conversion-in-worker-input branch from 4e657d4 to 2dac106 Compare March 14, 2021 21:35
@Qwebeck
Copy link
Member Author

Qwebeck commented Mar 14, 2021

wybierz typ umowy

Ma sens.
Zrobiłem tak mówisz

@Qwebeck Qwebeck requested a review from Ehevi March 14, 2021 21:38
Copy link
Contributor

@venglov venglov left a comment

Choose a reason for hiding this comment

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

Ogólnie super praca, mam tylko kilka drobnych uwag i pytań. Request changes z powodu literówek, wszystkie inne moje wątpliwości do twojej dyspozycji :)

src/components/namestable/use-worker-info.ts Show resolved Hide resolved
import { WorkerEmployementContractWorkNormSelector } from "./worker-employement-contract-work-norm-selector.component";
import { WorkerCivilContractWorkNormSelector } from "./worker-civil-contract-work-norm-selector.component";

export interface WorkerContractTypeDependentWorkTimeSelectorOptions extends FormFieldOptions {
Copy link
Contributor

Choose a reason for hiding this comment

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

Starałbym się unikać na tyle długich nazw, ponieważ poźniejsze ich wykorzystanie jest słabo czytelne, tym bardziej kiedy jest ich wiele. Może coś w stylu 'SelectorByContractTypeOptions'? Jendak jest to drobna uwaga, a nie request changes :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Racja
Trochę mnie poniosło xd
Zmieniłem na CombinedWorkNormSelector

const classes = useFormFieldStyles();

const contractOptions = useMemo(
() =>
Copy link
Contributor

Choose a reason for hiding this comment

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

tego pewien nie jestem, ale czy tu nie musi być (): typ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Słuszna uwaga, dodałem

workerInfo.previousWorkerName = name;
}
}, [mode, workerInfo, name]);
//#region event handlers
Copy link
Contributor

Choose a reason for hiding this comment

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

komentarze regionów w tym pliku są potrzebne?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nie są
Nie mniej jednak preferuję żeby one były ponieważ moim zdaniem zwiększają czytelność kodu dzieląc go na logiczne sekcje.

Ponadto to ma taką zaletę, że wszystko zawarte w regionie może być zwinięte
image

PS
W intellij to chyba wymaga dodatkowej konfiguracji

);

const contractTimeDropdownOptions = useMemo(
() =>
Copy link
Contributor

Choose a reason for hiding this comment

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

(): typ?

Copy link
Contributor

Choose a reason for hiding this comment

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

ide proponuje (): { dataCy: string; action: () => void; label: any }[]
nwm czy ma to sens

Copy link
Member Author

Choose a reason for hiding this comment

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

Mamy zdefiniowany interfejs ButtonData, więc użyłem go

import { ShiftCode } from "../../common-models/shift-info.model";
import { ContractType, WorkersInfoModel, WorkerType } from "../../common-models/worker-info.model";
import { ApplicationStateModel } from "../../state/models/application-state.model";
import { WorkerInfoExtendedInterface } from "./worker-edit/worker-edit.models";
Copy link
Contributor

Choose a reason for hiding this comment

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

może być krótszy

import { WorkerInfoExtendedInterface } from "./worker-edit";

);

const isWorkerWithSameNameExists = useCallback((): boolean => {
const isWorkerNameInvalid =
Copy link
Contributor

Choose a reason for hiding this comment

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

myślę że ta zmienna nie jest potrzebna

Copy link
Member Author

Choose a reason for hiding this comment

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

Preferuję wynosić wyniki operacji do zmiennych nawet jeśli ta zmienna będzie w następnej linii zwrócona w returnie.
Główna zaleta tego - to łatwiejsze debugowanie, bo czasami chcesz zobaczyć co zwraca funkcja będą w tej funkcji i wtedy taka zmienna na to pozwala.

Comment on lines 45 to 58
<Typography className={classes.label}>Ilość godzin</Typography>
<TextField
fullWidth
name="civilTime"
data-cy="input-civil-time"
value={convertToNormalHours(employementTime)}
type="number"
style={{
width: 100,
}}
className={classes.formInput}
onBlur={(event): void => setWorkerTime(toWorkerNorm(event.target.value))}
color="primary"
/>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ta wartość nie powinna być wprowadzana przez użytkownika? Bo u mnie nie to działa, strzałki góra-dół też nie, cały czas jest 160.
godziny
No, i policzalne godziny ;)

Copy link
Contributor

Choose a reason for hiding this comment

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

u mnie też nie działa

Copy link
Member Author

Choose a reason for hiding this comment

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

Dzięki za uwagę.
Poprawiłem, teraz działa dobrze

Copy link
Contributor

@prenc prenc left a comment

Choose a reason for hiding this comment

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

Sorry, ale nie podoba mi się to, że otwierasz drawer i od razu wszystko na czerwono się świeci. Raczej powinno być tak, że przycisk do zapisywania pracownika jest cały czas aktywny, a przy jego naciśnięciu pola są sprawdzane i jak coś jest nie tak to wyświetla się czerwona informacja.

Reszta dla mnie git. + to co Agata już powiedziała

@Qwebeck Qwebeck removed the request for review from mbielech March 17, 2021 20:07
Copy link
Member Author

@Qwebeck Qwebeck left a comment

Choose a reason for hiding this comment

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

Sorry, ale nie podoba mi się to, że otwierasz drawer i od razu wszystko na czerwono się świeci. Raczej powinno być tak, że przycisk do zapisywania pracownika jest cały czas aktywny, a przy jego naciśnięciu pola są sprawdzane i jak coś jest nie tak to wyświetla się czerwona informacja.

Zrobiłem tak, żeby komunikaty pojawiały się nie wcześniej niż po wprowadzeniu jakiejś informacji do odpowiednich pół

@Qwebeck Qwebeck requested a review from prenc March 17, 2021 21:46
@Qwebeck Qwebeck requested review from Ehevi and venglov March 17, 2021 21:46
Copy link
Contributor

@prenc prenc left a comment

Choose a reason for hiding this comment

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

UI się rozwala przy wpisywaniu etatu bardzo łatwo
image
Ogólnie jakieś dziwnie duże przerwy są pomiędzy kolejnymi elementami.

@Qwebeck Qwebeck force-pushed the TASK-304-work-hour-conversion-in-worker-input branch from af33ad5 to b82c730 Compare March 18, 2021 18:00
@Qwebeck
Copy link
Member Author

Qwebeck commented Mar 18, 2021

Dodałem scroll który pojawia się w momentach kiedy zoom jest za duży

image

@Qwebeck Qwebeck requested a review from prenc March 18, 2021 18:05
@Qwebeck Qwebeck merged commit 401b6eb into develop Mar 20, 2021
@Qwebeck Qwebeck deleted the TASK-304-work-hour-conversion-in-worker-input branch March 20, 2021 10:28
prenc added a commit that referenced this pull request Mar 22, 2021
* TASK-338 Enable database clear when error appears  (#249)

* Save file with proper name, save all db docs when error button clicked

* Modify database export and export all schedules in zip

* Set proper zip name

* Fix and extend filehelper test

* Move handle dummp to file helper, remove comments

* Fix file helper test

* Add custom types instead of inline dicts

* Save correct timestamp

* TASK-343 Handle rendering crushes at schedule level (#257)

* TASK-323 Add min char number indication in report issue modal (#262)

* Task 348 Enable undo on corrupted schedule page (#265)

* TASK-345 Improve descriptions of found schedule's issues (#263)

* TASK-371 Bug: wrong errors when 31-day month (#271)

* export workers (#267)

Co-authored-by: Tomasz Pęcak <[email protected]>
Co-authored-by: Paweł Renc <[email protected]>

* TASK-324 Reduce hour number based on previously scheduled shifts for L4 (#259)

* TASK-319 Export number of daytime employees information (#260)

* Task 291 Copy month to full schedule (including next month) (#272)

* Fixes bad key setting (#275)

* TASK-322 Bug: fix missing colors in Excel export for employees having no shifts (#258)

* TASK-333 && TASK-335 Asking about unsaved changes when exiting edit mode && disabling undo/redo/save buttons (#270)

* TASK-370 Fix restoring state on corrupted schedule page (#276)

* TASK-362 Parse workers info from excel (#269)

* TASK-375 Bug: app crashes when copying from month ending on sunday (#280)

* TASK-314 Another iteration over excel layout of exported schedule (#278)

* bugfixes

* implements function to decide font color

* added links

* small fixes

Co-authored-by: Tomasz Pęcak <[email protected]>

* TASK-389 Close issue drawer when exiting edit mode (#285)

* Bug fixed. Cypress passing.

* Added isEditMode watcher for auto drawer closing.

* TASK-376 Error modal doesn't appear on app error (#286)

* Handle error on higher tree level

* Add error message for testing purposes

* TASK-350 Keep shifts scheduled in next month's days  (#283)

* Add corrupted info to schedule state

* Stash branch changes

* Restore prev storage initialization

* Do not replace free shifts in first week

* TASK-387 Sort shifts in dropdown (#282)

* TASK-361 autocomplete component rendering fix (#284)

* TASK-304 Another iteration over drawer for managing workers (#279)

* TASK-388 Now edit state is properly false after leaving edit mode. BUGFIXED (#290)

* TASK-256 Add exporting employees' small calendar to pdf (#277)

* TASK-379 Add worker to single month (#289)

* TASK-339 & TASK-382 fix all console errors & increase folding performance (#288)

* TASK-391 fixed calculation of worker norm when added during the month with parttime contract. (#295)

* TASK-390 Stick footer to bottom of page, not viewport (#294)

* Change footer to be the end of the content, rather than sticked to the bottom of the screen. Remove electron block

* Footer always on the bottom of the page

* Repair jira like drawer after footer changes. Repair zarzadzanie tab

Co-authored-by: Tomasz Pęcak <[email protected]>
Co-authored-by: Ehevi <[email protected]>
Co-authored-by: Paulina <[email protected]>
Co-authored-by: Bohdan <[email protected]>
Co-authored-by: Vyacheslav Trushkov <[email protected]>
Co-authored-by: kopcion <[email protected]>
Co-authored-by: Jan Ślażyński <[email protected]>
Co-authored-by: Maciej Bielech <[email protected]>
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.

4 participants