Requests page #7537
Requests page #7537
Conversation
…into kl/data-processing
|
Something does not work when I am testing the feature with organization. I see three problems:
@Marishka17 they are probably server-side issues. |
| const updatedQuery = { ...query }; | ||
| const queryParams = new URLSearchParams(history.location.search); | ||
| for (const key of Object.keys(updatedQuery)) { | ||
| (updatedQuery as Indexable)[key] = queryParams.get(key) || null; | ||
| if (key === 'page') { | ||
| updatedQuery.page = updatedQuery.page ? +updatedQuery.page : 1; | ||
| } | ||
| } |
There was a problem hiding this comment.
We only have one query parameter, the code may be significantly simpler
There was a problem hiding this comment.
Yes but its our general approach. We do the same on other pages, I dont see the reason not to use it here. We can add another params later
| .cvat-requests-scrollbar { | ||
| &::-webkit-scrollbar { | ||
| background-color: #fff; | ||
| width: 16px; | ||
| } | ||
|
|
||
| &::-webkit-scrollbar-track { | ||
| background-color: #fff; | ||
| } | ||
|
|
||
| &::-webkit-scrollbar-thumb { | ||
| background-color: #babac0; | ||
| border-radius: 16px; | ||
| border: 6px solid #fff; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Why did you decide to use vendor-specific css selectors?
There was a problem hiding this comment.
I believe we cant make pretty scrollbar with standard selectors. It works fine in chrome as its our main supported browser
| dispatch(getRequestsAsync({ | ||
| ...query, | ||
| page: newPage, | ||
| })); |
There was a problem hiding this comment.
serverProxy:getRequestsAsync uses fetchAll. By the way, why???
If it already fetched all list, why do you call getRequestsAsync?
There was a problem hiding this comment.
Removed that call.
Dont we need to check for all requests status? There can be more than 10 in progress. We want notifications for those when they are completed
| @@ -495,3 +495,26 @@ export interface SerializedAPISchema { | |||
| url: string; | |||
| }; | |||
| } | |||
|
|
|||
| export interface SerializedRequest { | |||
| id?: string; | |||
There was a problem hiding this comment.
why having id is not guaranteed?
tha same about created_date and owner
There was a problem hiding this comment.
Yes. When we create task, we use the same request callback, so we create fake Request instances. We dont have an ID while uploading data, also it wouldnt be pretty to construct a created_date and owner here.
|
|
I already mentioned this, but did not get answer. Why is TTL 20 minutes for exports??? |
|
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| field_name=StorageType.TARGET, | ||
| ) | ||
| except ValueError as ex: | ||
| raise serializers.ValidationError(str(ex)) from ex |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Motivation and context
How has this been tested?
Checklist
developbranch(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)
License
Feel free to contact the maintainers if that's a concern.
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
cy.goBack()after export operations.Refactor
importingandbackupIsActiveacross multiple components.Tests
Documentation
Chores