-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add banner for scheduled maintenance #7284
Conversation
@normanrz I am unsure about the permission system here. Who should be allowed to create/update scheduled maintenances in the database?
|
Either we do it just for superadmins, which seems fine to me, or we scope the maintenance banners to orgs. |
I have some more questions :)
|
Yes, either the current or the next maintenance should be shown. No more than 1 banner.
I think the message should be kept short to fit in the banner. |
this should be a basic frontend implementation without storing the maintenance info in the redux store (moved to new branch). |
@fm3 could you help me with the merge conflicts in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code looks quite good already, but I still have some feedback :)
frontend/stylesheets/main.less
Outdated
.ant-alert-message { | ||
margin-left: 5px; | ||
} | ||
.ant-alert-banner { | ||
position: absolute; | ||
z-index: 1000; | ||
width: 100%; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are antd classes, right? Please move these (and the rule in line 121f) to antd_overwrites.less
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay! when does something count as overwriting?
there are multiple CSS rules for antd in main.less, e.g. in l. 72 and I am not sure I understand when to write antd rules where
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, it's not very clear right now. I moved another rule, but the others rules mostly use antd class names in combination with other descriptors (e.g., #main-container > section > .ant-layout-header
). This means that only specific occurrences of antd components are changed. In the overwrites module, on the other hand, the rules are mutating all occurrences of the mentioned antd components. So, this is can be used as a rule of thumb :)
591ac33
to
00e3a39
Compare
Nice! Works well 👍 However, there's an oddity about the banner when the user scrolls in the dashboard. See these screenshots: I see two possible solutions:
The first option is probably easier. I hope that it behaves well then. If not, the second option might be the better approach (since the layout in the tracing view should forbid scrolling anyway). |
with the first option I faced the problem that the lower position wasn't taken into account, so the switching didnt work any more. thus I implemented the second version. this leads to some views (at least Statistics > Overview) scrolling, not sure whether that is a problem. other than that it seems to be working fine! |
…ongoing maintenance for 60s; fix store listening
const INTERVAL_TO_FETCH_MAINTENANCES_MS = 60000; | ||
|
||
export function MaintenanceBanner() { | ||
const { activeUser, uiInformation } = Store.getState(); | ||
const activeUser = useSelector((state: OxalisState) => state.activeUser); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dieknolle3333 just fyi, I fixed the store access here. When rendering react components, it's always important to properly hook up with the store so that the component updates when the store updates. This listener can be set up with connect
(from react-redux
) or in case of functional components useSelector
(which is better in my opinion since it's less verbose). Your access to Store.getState()
is fine in event handlers (e.g., onClick handler in a button) when one doesn't need the synchronization. However, during rendering this would mean that the component gets outdated at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I understand!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great :) I fixed some smaller stuff and now think that the PR should be ready to go 🚀
URL of deployed dev instance (used for testing):
Steps to test:
Backend:
curl -X POST 'http://localhost:9000/api/maintenances' -H 'X-Auth-Token: secretSampleUserToken' -H "Content-Type: application/json" -d '{"startTime":1692272319000, "endTime":1692272320000, "message":"a message!"}'
(adapt timestamps to something in the future or current, use https://www.epochconverter.com/ for millisecond unix timestamps)curl -X DELETE 'http://localhost:9000/api/maintenances/64de02abee0100c103ab66b6' -H 'X-Auth-Token: secretSampleUserToken'
(replace id)curl -X PUT 'http://localhost:9000/api/maintenances/64de0390ee0100a006ab66cc' -H 'X-Auth-Token: secretSampleUserToken' -H "Content-Type: application/json" -d '{"startTime":1692272319000, "message":"a message!!!"}'
GET api/maintenances/listCurrentAndUpcoming
(this is what the frontend uses)Frontend:
TODOs:
GET api/maintenances/listCurrentAndUpcoming
)Issues:
(Please delete unneeded items, merge only when none are left open)