flag to hide list item from UI #3
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We need Vikunja to support 100.000 and more list items.
Current UI is not able to handle 10.000 lists.
The list items will probably not have meaningful name
My idea is to have in list model flag to decide if this item is useful for UI.
I think the proper way to handle this would be pagination. Right now, all lists are loaded into the browser, processed and then rendered in the UI which probably causes all the problems. Doing this with pagination would mean a few things:
I'm not even sure if there is a performant way to show that many lists at once so you'll probably need pagination either way.
In general, pagination would be good improvement.
For our needs I am sure we need the flag to disable list from UI:
@konrad Is the
hide_from_ui
flag something you see as a problem to add to the main branch?I think a
hide_from_ui
flag takes away the "unopinionatedness" (if you can call it that) from the api. IMHO the API should not make assuptions about how its being used, therefore a ui flag would not feel like a good idea.Even if likely more work than a simple flag the proper way to fix this problem would be paginating tasks I think. That way other people with a lot of lists would also benefit. A
hide_from_ui
flag needs to explicitely be set, pagination is implicit.small objection to
unopinionatedness
:-) ... if there is already tablefavorites
with columnkind
... then it could be renamed toflags
with added propertytype
where
type
could befavorite
,hiden
... not most efficient for searching, but aligned how the UIfavorite
flag is storedAt this point I don't see pagination as solution for us, becasue our list title will not be meaningful for user.
I would like to have visible lists like
personal
,ambulance
,ministry of health
and then list per each patient in Curo without any personal data.Okay, I think I now understand better what you want to achieve.
I'm still not sure whether a flag like the one you proposed is the way to go here but maybe it's just the naming that bothers me.