feat: rename lists to projects #2697
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2697
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/rename-lists-to-projects"
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?
Frontend PR for vikunja/api#1318
All cypress tests in this PR will fail until the API gets merged.
Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2697-feature-rename-lists-to-projects--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
feature/rename-lists-to-projectsto feat: rename lists to projectsf4f324576c
tof54aeb8e0b
The cypress tests now work locally. The ci will fail until the API PR is merged.
@ -1,57 +0,0 @@
import {createFakeUserAndLogin} from '../../support/authenticateUser'
Did you use git mv for files with lots of changes? Asking because this will break a lot of history.
If not: maybe we can still do this.
I might have an idea how this could be done.
I did but this might have been broken by the rebase.
What do you have in mind?
You mean in order to restore the history again?
yes. My best idea right now is to start a new branch from main and copy the changes from this branch over. That would keep the latest history but basically remove all commits from this PR into one giant commit. Not sure what's better.
See my comment here: #2697 (comment)
We should make sure that:
You will hate me for this question: but why did we want to rename lists to projects again? Asking because:
Because a list now does more than just being a list. Mostly because of the different views. When I started Vikunja these did not exist so calling it a list made sense back then. I just feel like it does not make sense now.
You mean with vikunja/api#1362?
What do you mean?
Filters are not ideal, yes, but I think that's something for another PR.
Okay I checked all files for which there is a renaming history. The other files are basically unreviewable.
You could easily change this if you:
@ -11,3 +11,3 @@
beforeEach(() => {
NamespaceFactory.create(1)
ListFactory.create(1)
const projects = ProjectFactory.create(1)
Why the unused variable?
Not used, removed it.
@ -21,2 +21,2 @@
sed -i "s/listen 80/listen $VIKUNJA_HTTP_PORT/g" /etc/nginx/nginx.conf
sed -i "s/listen 443/listen $VIKUNJA_HTTPS_PORT/g" /etc/nginx/nginx.conf
sed -i "s/projecten 80/projecten $VIKUNJA_HTTP_PORT/g" /etc/nginx/nginx.conf
sed -i "s/projecten 443/projecten $VIKUNJA_HTTPS_PORT/g" /etc/nginx/nginx.conf
These lines are wrong
Done
@ -53,3 +53,3 @@
<div class="namespace-title" :class="{'has-menu': n.id > 0}">
<BaseButton
@click="toggleLists(n.id)"
@click="toggleProjects(n.id)"
Feedback general to this file:
I think most renames in this file should be reverted.
Reason beeing: I see the list here as a reference to "menu list" and not to project list, even if there might be projects lists inside.
Mhh yes. TBH I'd like to keep it the way it is currently since the navigation has to be reworked substantially for the move from namespaces -> projects and a lot of the effort to make it nice now would be wasted then anyway.
This is exactly why I want to keep the diff minimal.
I have already a branch where I did a lot of stuff going in that direction. Would like to make the merge as easy as possible.
I've reverted a few changes. Now it should only contain those where it makes sense, most notably the class names are still the old ones.
@ -87,2 +86,3 @@
group="namespace-projects"
@start="() => drag = true"
@end="saveListPosition"
@end="saveProjectPosition"
Unsure: Doesn't describe saveListPosition this better? Since it's about the list order of the project.
Id's say it's a project position in a list so both work. This makes it clear the function deals with projects (even though that could be inferred from the function itself)
That makes sense. Might be another entity inside the navigation that also can save its position
@ -95,3 +95,3 @@
:component-data="{
type: 'transition-group',
name: !drag ? 'flip-list' : null,
name: !drag ? 'flip-project' : null,
Might be that the flip animation is broken either way, but the class name needs to be aligned.
In the styles below I could still find a
.flip-list-move
which should be.flip-list-move
if you still want to rename it after considering my first comment in this file.@ -105,3 +105,2 @@
<li
class="list-menu loader-container is-loading-small"
:class="{'is-loading': listUpdating[l.id]}"
class="project-menu loader-container is-loading-small"
Unsure if we should update these class names:
project-menu => By naming it after the projects we make this dependant on the project. But maybe we want to make a list of tags or whatever and could reuse the same class there.
@ -111,2 +110,2 @@
class="list-menu-link"
:class="{'router-link-exact-active': currentList.id === l.id}"
:to="{ name: 'project.index', params: { projectId: l.id} }"
class="project-menu-link"
Same here
@ -79,4 +79,3 @@
icon: '<svg viewBox="0 0 24 24"><rect fill="none" rx="0" ry="0"/><path fill="currentColor" fill-rule="evenodd" clip-rule="evenodd" d="M6.5281 3.7002H3.5281C3.1981 3.7002 2.9281 3.9702 2.9281 4.3002V7.3002C2.9281 7.6302 3.1981 7.9002 3.5281 7.9002H6.5281C6.8581 7.9002 7.1281 7.6302 7.1281 7.3002V4.3002C7.1281 3.9702 6.8581 3.7002 6.5281 3.7002ZM5.9281 6.7002H4.1281V4.9002H5.9281V6.7002ZM3.5281 9.90015H6.5281C6.8581 9.90015 7.1281 10.1701 7.1281 10.5001V13.5001C7.1281 13.8301 6.8581 14.1001 6.5281 14.1001H3.5281C3.1981 14.1001 2.9281 13.8301 2.9281 13.5001V10.5001C2.9281 10.1701 3.1981 9.90015 3.5281 9.90015ZM4.1281 12.9001H5.9281V11.1001H4.1281V12.9001ZM3.5281 16.1001H6.5281C6.8581 16.1001 7.1281 16.3701 7.1281 16.7001V19.7001C7.1281 20.0301 6.8581 20.3001 6.5281 20.3001H3.5281C3.1981 20.3001 2.9281 20.0301 2.9281 19.7001V16.7001C2.9281 16.3701 3.1981 16.1001 3.5281 16.1001ZM4.1281 19.1001H5.9281V17.3001H4.1281V19.1001ZM9.72817 6.4002H20.7282C21.0582 6.4002 21.3282 6.1302 21.3282 5.8002C21.3282 5.4702 21.0582 5.2002 20.7282 5.2002H9.72817C9.39817 5.2002 9.12817 5.4702 9.12817 5.8002C9.12817 6.1302 9.39817 6.4002 9.72817 6.4002ZM9.72817 11.4001H20.7282C21.0582 11.4001 21.3282 11.6701 21.3282 12.0001C21.3282 12.3301 21.0582 12.6001 20.7282 12.6001H9.72817C9.39817 12.6001 9.12817 12.3301 9.12817 12.0001C9.12817 11.6701 9.39817 11.4001 9.72817 11.4001ZM9.72817 17.6001H20.7282C21.0582 17.6001 21.3282 17.8701 21.3282 18.2001C21.3282 18.5301 21.0582 18.8001 20.7282 18.8001H9.72817C9.39817 18.8001 9.12817 18.5301 9.12817 18.2001C9.12817 17.8701 9.39817 17.6001 9.72817 17.6001Z"/></svg>',
},
{
name: 'ordered-list',
This is wrong
Fixed.
@ -76,3 +76,1 @@
name: 'unordered-list',
action: EasyMDE.toggleUnorderedList,
title: i18n.global.t('input.editor.unorderedList'),
name: 'unordered-project',
This is wrong
Fixed.
@ -17,3 +17,3 @@
</message>
<dl class="shortcut-list">
<dl class="shortcut-project">
This is a list of shortcuts. Not a project.
Most definitley. Fixed.
@ -59,3 +59,3 @@
}
.shortcut-list {
.shortcut-project {
Same here
@ -18,3 +18,3 @@
{{ $t('misc.next') }}
</router-link>
<ul class="pagination-list">
<ul class="pagination-project">
This is a list of pagination items
Fixed.
@ -9,3 +9,3 @@
<CustomTransition name="fade">
<div class="notifications-list" v-if="showNotifications" ref="popup">
<div class="notifications-project" v-if="showNotifications" ref="popup">
This is a list of notifications
Fixed.
@ -156,3 +156,3 @@
}
.notifications-list {
.notifications-project {
This is a list of notifications
Fixed.
@ -232,2 +229,2 @@
table: t('list.table.title'),
kanban: t('list.kanban.title'),
const availableViews = computed<Record<ProjectView, string>>(() => ({
project: t('project.list.title'),
The view is still called
list
:That's true. Fixed.
@ -31,3 +31,3 @@
import {includesById} from '@/helpers/utils'
import ListUserService from '@/services/listUsers'
import ProjectUserService from '@/services/projectUsers'
Okay this renaming here helps a lot: Allthough 'project' is a verb it doesn't make as much sense as the verb 'list'. I always used to read this as 'list-the-users-service', which is not exactly what it does.
@ -0,0 +7,4 @@
/>
<ColorBubble
v-if="showProjectColor && projectColor !== '' && currentProject.id !== task.projectId"
This addition shouldn't be part of this PR. This PR is so huge that we really should not do more than the renaming.
What's interesting about this is I noticed this only because the test broke checking this. Not sure why.
I could either
Before might be better.
Of course, the best solution would be to fix whatever caused the test to fail but I fear that would be a change like this.
Do it before
PR: #2975
@ -43,3 +43,3 @@
/**
* This mixin provides a base set of methods and properties to get tasks on a list.
* This mixin provides a base set of methods and properties to get tasks on a project.
Maybe we can write here now:
This mixin provides a base set of methods and properties to get tasks.
Done
@ -46,2 +45,3 @@
* This mixin provides a base set of methods and properties to get tasks on a project.
*/
export function useTaskList(listId, sortByDefault = SORT_BY_DEFAULT) {
export function useTaskList(projectId, sortByDefault = SORT_BY_DEFAULT) {
I use
list
usually as a suffix to indicate that there are multiple items. E.g. if a have a component with a for loop I will add afoobar__list
to the wrapper with thev-for
and afoobar__item
to the individual items inside. This is the logic used for naming this. Maybecollection
would be a better wording now, since after the merge of this branch 'list' will mostly refer to the layout not the data format.ohh so
listId
here is not the id of the list but some identifier about the current "list of things"? The way it gets used in getAllTasksParams` looked like a (now) project id.Tbh I'm unsure about this. I have also adjusted this massively and don't rembember the original function as it is here very well.
Can we keep this for now as useTaskList? I could still change the name later (maybe just
useProject
?).so leaving it as it is now? The name of the function did not change, only the parameter.
Yes, that's what I meant :)
@ -99,3 +99,3 @@
// Only listen for query path changes
// Only projecten for query path changes
listen
Done.
@ -423,3 +423,3 @@
"import": "Import your data into Vikunja",
"description": "Click on the logo of one of the third-party services below to get started.",
"descriptionDo": "Vikunja will import all lists, tasks, notes, reminders and files you have access to.",
"descriptionDo": "Vikunja will import all projects, tasks, notes, reminders and files you have access to.",
Probably this should stay lists, because in other tools this is not always called projects.
yes! Done.
@ -531,2 +531,2 @@
"unorderedList": "Unordered List",
"orderedList": "Ordered List",
"unorderedProject": "Unordered Project",
"orderedProject": "Ordered Project",
Wrong!
whooops
Fixed.
@ -903,1 +901,3 @@
"switchToListView": "Switch to list view",
"project": {
"title": "Project Views",
"switchToProjectView": "Switch to project view",
The view stays a list.
Fixed!
@ -24,3 +23,1 @@
import LinkShareAuthComponent from '@/views/sharing/LinkSharingAuth.vue'
const ListNamespaces = () => import('@/views/namespaces/ListNamespaces.vue')
const TaskDetailView = () => import('@/views/tasks/TaskDetailView.vue')
import UpcomingTasksComponent from '../views/tasks/ShowTasks.vue'
Why the change to
..
instead of@
?Not intended, probably caused by the rebase.
Can we keep the
@
to keep it aligned?Sure, changed all imports so they do that.
@ -358,2 +357,3 @@
name: 'project.index',
redirect(to) {
// Redirect the user to list view by default
// Redirect the user to project view by default
This redirects indead to the
list
view!@ -361,2 +361,2 @@
const savedListView = getListView(to.params.listId)
console.debug('Replaced list view with', savedListView)
const savedProjectView = getProjectView(to.params.projectId)
console.debug('Replaced project view with', savedProjectView)
Should be:
I'd argue this is a project view here. It can be any of the four views (or at least that's what I meant when I originally added the log).
I thought that it was refering to the default view which is the 'list'. That's why it's replacing it. at all. If there is no saved view nothing will be replaced and the default stays list.
okay that makes sense.
Changed!
@ -0,0 +4,4 @@
export default class ProjectUserService extends AbstractService {
constructor() {
super({
getAll: '/projects/{projectId}/projectusers',
Can we make the endpoint here only
/projects/{projectId}/users
instead?What should we use to get the users a project is currently shared with then? Because that's
/projects/{projectId}/users
right now.The difference between the two is
/projectusers
also returns users who have access to a project because they're part of a team.The term
members
comes to my mind, but I guess this is all not something that should be changed here. If theproject
prefix could be deleted I would have found it fine to include it in this PR, but with your explanation it doesn't make much sense anymore.@ -65,1 +63,3 @@
if (l.subscription === null || l.subscription.entity !== 'list') {
// Check for each project in that namespace if it has a subscription and set it if not
n.projects.forEach(l => {
if (l.subscription === null || l.subscription.entity !== 'project') {
Just a question here: How was this info saved in the DB? Will the migration take care the the entitiy now can be called
project
instead oflist
?The migration will Take care of that. The DB only saves integers.
Cool! :)
@ -344,2 +343,3 @@
let foundProjectId = null
// Uses the following ways to get the list id of the new task:
console.log('find', {projectName, projectId})
Here is some leftover
whoops, removed.
@ -347,3 +349,1 @@
if (listName !== null) {
const list = listStore.findListByExactname(listName)
foundListId = list === null ? null : list.id
if (typeof projectName !== 'undefined' && projectName !== null) {
Is this a changed new condition or are we reverting here something that should only check for
!== null
?I discovered how it failed when
projectName
was undefined and it should behave the same as the if. It's a changed new condition.@ -37,0 +37,4 @@
$projects-per-row: 5;
$project-height: 150px;
$project-spacing: 1rem;
Where are these coming from?
rebase, mostly. Removed them since you already moved them elsewhere.
@ -9,3 +9,3 @@
background: var(--grey-200);
// FIXME: only used in ListLabels.vue
// FIXME: only used in ProjectLabels.vue
I think you didn't rename that, which would make sense, since it "lists the labels"
yes 👍
@ -0,0 +6,4 @@
$filter-container-top-default: -59px;
$filter-container-top-link-share-gantt: -133px;
$filter-container-top-link-share-project: -47px;
This is for the "list-view" so it should stay
$filter-container-top-link-share-list
Correct. Fixed!
@ -0,0 +97,4 @@
margin-top: calc(#{$filter-container-top-link-share-gantt} - 5rem);
}
.link-share-container .project-view .filter-container {
Should stay
list-view
Done.
@ -0,0 +98,4 @@
}
.link-share-container .project-view .filter-container {
margin-top: $filter-container-top-link-share-project - 10px;
This is for the "list-view" so it should stay
$filter-container-top-link-share-list
Done
@ -0,0 +102,4 @@
}
.link-share-container.project\.table-view,
.link-share-container.project\.project-view {
Should stay
.list-view
.Done.
@ -20,2 +20,2 @@
&.list\.gantt-view,
&.list\.kanban-view {
&.project\.gantt-view,
&.project\.kanban-view {
Unsure what list is meant with this.
I think the literal list (the one now called "project").
@ -32,3 +32,3 @@
.link-share-container:not(.has-background) {
.list-view {
.project-view {
Should stay
.list-view
@ -25,3 +25,3 @@
)
// This code listens for the user's confirmation to update the app.
// This code projectens for the user's confirmation to update the app.
listens
@ -12,3 +12,3 @@
icon: IconProp
mask?: IconLookup
listItem?: boolean
projectItem?: boolean
Wrong!
@ -15,3 +15,3 @@
</message>
<add-task
@taskAdded="updateTaskList"
@taskAdded="updateTaskProject"
This should either:
updateProject
.Yes. I've updated it.
@ -99,3 +99,3 @@
const deletionScheduledAt = computed(() => parseDateOrNull(authStore.info?.deletionScheduledAt))
// This is to reload the tasks list after adding a new task through the global task add.
// This is to reload the tasks project after adding a new task through the global task add.
// This is to reload the project after adding a new task through the global task add.
(remove
tasks
)@ -103,3 +103,3 @@
const showTasksKey = ref(0)
function updateTaskList() {
function updateTaskProject() {
See above.
@ -55,1 +52,3 @@
{{ $t('namespace.createList') }}
<p v-if="n.projects.length === 0" class="has-text-centered has-text-grey mt-4 is-italic">
{{ $t('namespace.noProjects') }}
<BaseButton :to="{name: 'projects.create', params: {namespaceId: n.id}}">
Didn't check, but shouldn't this be
name: 'project.create'
since list was also singular here.Yes, it should! Nice catch.
Fixed.
@ -0,0 +1,324 @@
<template>
<ProjectWrapper class="project-project" :project-id="projectId" viewName="project">
@ -0,0 +50,4 @@
<template #default>
<div
:class="{ 'is-loading': loading }"
class="loader-container is-max-width-desktop project-view"
This should stay
list-view
@ -0,0 +55,4 @@
<card :padding="false" :has-content="false" class="has-overflow">
<add-task
v-if="!project.isArchived && canWrite"
class="project-view__add-task"
This should stay
list-view__add-task
@ -0,0 +116,4 @@
</template>
<script lang="ts">
export default { name: 'Project' }
This should stay the
List
view.@ -0,0 +313,4 @@
}
}
.project-view__add-task {
This should stay
list-view
@ -0,0 +36,4 @@
<BaseButton class="unsplash-credit__link" href="https://unsplash.com">{{ $t('project.background.poweredByUnsplash') }}</BaseButton>
</p>
<ul class="image-search__result-project">
This is a
result-list
@ -0,0 +236,4 @@
color: var(--grey-800);
}
.image-search__result-project {
This is a
result-list
Would have proably been cheaper to use typescript consequently and name the list view list layout, since 'view' is almost a synonym for pages. Then again 'layout' has its own semantics in Nuxt… :D
No has nothing to do with that branch. I mean something like 'Inbox'. Or 'Foobar' (where I put stuff that doesn't belong anywhere else).
Even If I name something 'Longterm' it isn't really a project.
This is more about how we use filters internally. What I mean is:
So what I mean is that the analogy that we had until now "A filter is a kind of a list" doesn't work anymore.
True, but not what I meant :D
Yeah well if only I'd known that when I started Vikunja 4 years ago :D
Not sure if I understand you correctly, but there will be a default Project "Inbox" instead of a new empty namespace once that PR other is merged.
I think it's fine to have a project like that where you put stuff that does not belong anywhere else, even if it does not make sense to call that a project. The rename is a compromise between lists being more than a simple list and use-cases like that.
That is true. This is something that might change with the move from namespaces -> projects, not sure about that yet.
:D
Oh that's cool.
Absolutely, I just wanted to point out the consequences. It similar to that it doesn't make sense to put movies in folders.
All good. As said, mostly wanted to understand and point out 👍
@dpschen Anything else missing? From my pov this is all good now.
@ -75,3 +75,3 @@
<table
class="table has-actions is-striped is-hoverable is-fullwidth link-share-list"
class="table has-actions is-striped is-hoverable is-fullwidth link-share-project"
This is the list of shared links
Althought it probably should be a table.
The class isn't even used anywhere. I've removed it.
@ -23,3 +23,3 @@
import UpcomingTasksComponent from '@/views/tasks/ShowTasks.vue'
import LinkShareAuthComponent from '@/views/sharing/LinkSharingAuth.vue'
const ListNamespaces = () => import('@/views/namespaces/ListNamespaces.vue')
import ListNamespaces from '@/views/namespaces/ListNamespaces.vue'
Now these are not a dynamic imports anymore.
Fixed.
Can we close this in favor of #2978
Yes.