show path information of files and folders - on both sides - enhancement ?

[roomanus]

Hello,
this is a new try on parts of a previously made suggestion (#1797, #1791)
Let's say you have a rather complex, recurring standard folder structure per managed project in place and want to share parts of this with various users within nextcloud. User 1 shares content, user 2 receives the shares.
So the "sharer" side could look like this:

and his activity stream:

On the receiving side it looks a bit different:

Wouldn't it be possible to also show the full path as it is shown for name matches within user 1's view?
I think, at least within the filters of the files section it would make sense as, especially in this case but probably in others as well there is a lot information within the actual path, so showing the path in grey and the actual share in black would be a very decent but helpful enhancement.
Probably there are some cons which i don't see or know....

BTW: nextcloud 11.0.3 (stable) - 11.0.3.2 on ubuntu 16.04

Thanks in advance. All the best.

[jancborchardt]

The thing with showing the full path on the receiver side is that initially the shares land in the root folder. So the path is absolutely correct, and also that it’s called foldername (2) etc. If as a recipient you move the folder in a subfolder and change the name to also be foldername then the full path will be shown in the share view as you request. ;)

About the issue with the full path not being shown for same-named folders/files in the Activity app: Can you open an issue in the Activity app repository at https://github.com/nextcloud/activity/issues – cc @nickvergessen

[nickvergessen]

Closing as per above.

And implementing magic to check if the same name was already rendered somewhere in the activity stream and then even replace the older appearances is really out of scope for the activity app either.

[jancborchardt]

@nickvergessen it wouldn’t need to replace the older appearances, but at least saying »… shared foldername (2) with you« would be correct and feasible, right? Cause that’s what the local folder name is.

[roomanus]

Hello jancborchardt,
thanks for the explanation. The fact that the share lands in the root folder clears and explains everything further on the recipient side, even though it doesn't change the situation. I'm afraid i have to rethink our folder stucture instead to keep it overseeable...
As nickvergessen said and i see, it doesn't make any sense opening an issue in the activity app repo...

Anyway, thanks a lot...

[roomanus]

@jancborchardt of course it would be more consistent then...

[nickvergessen]

Ah now I see what you mean, I will see if that is fixable

[nickvergessen]

Hmm doesn't look like. The problem is that within the sharing, we don't want to set up the file system for all recipients to check if they already have a folder with the same name, so the activity is created with the wrong information...

[jancborchardt]

@nickvergessen @roomanus that is something which could be created an issue of though, to maybe have it fixed in the future? Because now it’s really strange if you have shares called the same – which are called differently in the Files app, but not in the Activities app.

[nickvergessen]

It's only the share activity that is wrong, all follow up activities are correct.

[roomanus]

@jancborchardt @nickvergessen it's up to to you guys..:)
as of laymen position i's say the bare minimum would be the modified (1, 2, 3) share name represented in the activity stream as all other files or folders are. Still not possible to clearly distinguish between them but consistent in their naming. As @nickvergessen said, only the initial share seems to be wrong, ongoing changes within the share are show with additional numbers.

[roomanus]

and by the way, if you move a share into a self created folder and back:

no Placeholder or something for root folder.