Core: Overview page of pending+rejected shares

Created on 20 Jan 2015  Â·  63Comments  Â·  Source: owncloud/core

If a user unshares a file from themself there is no way to bring the share back. We should have a sidebar entry "rejected shares" (or similar) which lists all shares a user unshared from themself until the owner unshares the file. This enabled the user to bring back a share if they unshared the file by accident. Currently there is no way to bring back a share after the user unshared it from themself.

enhancement sharing p2-high

All 63 comments

Good idea!

@owncloud/designers

What about listing incoming shares in such an overview page in the sidebar too. see https://github.com/owncloud/core/issues/4435#issuecomment-73251295

What about listing incoming shares in such an overview page in the sidebar too

That's exactly my plan :smile:

It is also listed here as "nice to have": https://github.com/owncloud/core/issues/12285#issuecomment-63823361

Awesome :)

We should have a situational »Pending shares« sidebar entry which will list both incoming and rejected shares – if there are any.
Incoming should be at the top, and rejected ones sorted at the bottom and greyed out.

For incoming shares you can accept or reject them, and for rejected shares you can re-accept (undo rejection) or permanently delete. (Otherwise you’re stuck with a »pending shares« section for longer than you want.)

Sounds good

  • [ ] Multiple incoming shares UX is broken #13690

from @cdamken 00002646

@MTRichards This was a requested feature from @cdamken

Past feature freeze -> 8.2

Past this feature freeze too –> 9.0

@PVince81 @cmonteroluque still no work on this has been done. So no 9.0...

Moving to 9.1 then. @cmonteroluque

This would go along very well with the other proposed feature of having users accept local shares too: https://github.com/owncloud/core/issues/19153

@PVince81 fully agree.
@MTRichards FYI

Concur. Will take a look in the context of 9.1.

This page would also allow to re-accept shares that were rejected / unshared from self by group members, as requested here https://github.com/owncloud/core/issues/19159

nod

We're past feature freeze, moving to 9.2

Wouldn't that mean an API that returns a list of the shares, with a state that tells if it is accepted or not? Remember that we want to use the same APIs over all clients, also the web client. The desktop client currently gives the user the chance to accept or decline a share through the notification API (very handy...) but once accepted or declined, it can not display a list again.

is there a way to prevent the user to delete a folder shared with him? Thank you

@jsteremberg yep, just uncheck the »can edit« permission, then they can not edit or delete anything. :)

@jancborchardt I did, but even though the real files are not being deleted, the user can still delete the folder that was shared with him from his "view". Can I disable the option to delete or even make the folder disappear from their view, completely?

@jsteremberg not at this point, no.

Database hack (workaround) how to revert group-wise shared folders that a certain user (member of the group) unshared for him/herself (Thanks to PVince81):

  • to show you the „opted-out“ shares, enter SQL command:
    select * from oc_share where permissions=0 and share_type=2
  • if you delete the undesired entry, the share will be visible again for the user from the „share_with“ column

Here is solution based on @brozkeff last post, simple trigger in MySQL db, that prevents delete of shared folder:

CREATE TRIGGER `_UndoUserShareDelete` BEFORE INSERT ON `oc_share`
 FOR EACH ROW BEGIN
    IF (NEW.permissions=0 and NEW.share_type=2) THEN 
        signal sqlstate '45000';
    END IF;
END;

When this trigger exist then users will not have ability to delete shared folders.

I'd love a "Prevent from deleting" option for shared files and folders.

Current behaviour is not really really bad, but it would be really nice being able to avoid removing some really important files and folders. It's not that uncommon that one wants to make sure that certain users can't delete a folder.

@Aka4Code, would it be also possible to have a similar trigger but to prevent user from renaming a shared folder ?

@Aka4Code your trigger work like a charm

@pmaier1 backlog ?

Note that some of the API work was already done here https://github.com/owncloud/core/pull/24439

This trigger worked for me to avoid share rename and/or deletion:

CREATE TRIGGER `_UndoUserShareDeleteOrRename` BEFORE INSERT ON `oc_share`
    FOR EACH ROW BEGIN
    IF (NEW.share_type=2) THEN 
    signal sqlstate '45000';
    END IF;
    END;

If the share has been already renamed before to create this trigger, the user can continue renaming it.

@mapeze When trying to create the trigger I get the following error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'END IF' at line 1

I Have Mysql 5.6 on Debian 8.

I corrected the code format. Try now.

@mapeze
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| owncloud |
+--------------------+
2 rows in set (0.00 sec)

mysql> use owncloud
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> CREATE TRIGGER _UndoUserShareDeleteOrRename BEFORE INSERT ON oc_share
-> FOR EACH ROW BEGIN
-> IF (NEW.share_type=2) THEN
-> signal sqlstate '45000';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 4
mysql> END IF;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'END IF' at line 1
mysql> END;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'END' at line 1
mysql> CREATE TRIGGER _UndoUserShareDeleteOrRename BEFORE INSERT ON 'oc_share' FOR EACH ROW BEGIN IF (NEW.share_type=2) THEN signal sqlstate '45000';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''oc_share' FOR EACH ROW BEGIN IF (NEW.share_type=2) THEN signal sqlstate '45000'' at line 1
mysql>
mysql>
mysql> CREATE TRIGGER _UndoUserShareDeleteOrRename BEFORE INSERT ON oc_share FOR EACH ROW BEGIN IF (NEW.share_type=2) THEN signal sqlstate '45000';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

@mapeze mysql> SELECT @@version;
+-----------------+
| @@version |
+-----------------+
| 5.5.53-0+deb8u1 |
+-----------------+
1 row in set (0.00 sec)

mysql>

You need first to change delimiter to for example // and then execute this code. More info here http://stackoverflow.com/questions/1346637/what-does-delimiter-do-in-a-trigger
After delimiter change to //, paste the code, hit enter, type // and hit enter.

How has a high-severity issue like this one no Assignee after 2 years?

Any news?

Estimate: 3-5 md

Hi.
I want to prevent a user that I share a folder from being able to rename the folder. I do not give you any permission and yet you can rename it

@kernelpanic01 the receiver of the share cannot rename the share, they are just renaming their local "view" of the share.
1) That sort of renaming needs to be possible in general, e.g. if userA shares folder "stuff" with userB, but userB already has their own folder "stuff" then "the system" has to do something to provide userB with the share, as well as keep userB's own "stuff" folder. Given that that has to be possible, then userB also needs to be able to rename some folder shared with them as "stuff" so that they can make their own local folder"stuff".
2) On the webUI and API it is possible to control these things, but once userB syncs down to some local client (e.g. their Windows laptop) then they can rename the folder that was shared with them - the client needs to be able to then do something. There is a general issue with trying to prevent users from renaming things - they will rename anyway on client systems where ownCloud does not have control, and so life is easier if ownCloud minimizes how much it tries to fight that.

  • accept/reject/unshare from self for user shares
  • for group shares only accept/reject: when rejected, it stays in the list

@felixheidecke can you provide a design with mock up ?

Let us know if you have questions.

We need to think about what columns to display, etc.

@felixheidecke also a few old relevant questions about UX interaction: https://github.com/owncloud/core/pull/24439#issuecomment-217873494

This was successfully added to my backlog 👍

This was successfully added to my backlog

Backlog? We want to take on this topic in the next iterations of core so we need an idea and design proposal.

My personal Backlog :-) So it's on the list of things to do.

My idea is to enrich the existing _shared by me_, _shared with me_ sections with this information.
It's just a sketch. Icons and colors are TBD.

rejected-pending-shares

We could allow sorting by "status" which includes _shared_, _rejected_ and _pending_.

@pmaier1 is this still of interest?

@pmaier1 is this still of interest?

Yes, definitely. This is a prerequisite for plans we have for the next server release.

@felixheidecke and I like your idea of reusing "Shared with you", looks promising.

Summary of discussion with @pmaier1 @felixheidecke:

  • implement a mock up and do some usability testing
  • for mock up, use https://github.com/owncloud/core/issues/13495#issuecomment-348484906 as base
  • only for "Shared with you" section, no change in "Shared with others" for now
  • accept/reject action must be inside the row, need to find different approaches
  • we agreed to not have accept/reject action in sidebar
  • add column header for the state, sort by state by default: pending shares first, accepted shares next, and at the end rejected shares

I'm not sure about the special icons though, they'd only apply for folder shares, not file shares. I'd do away with the icons for now and only keep the state text. Maybe we could change the row background color ?

@PVince81 and @pmaier1 … I stumbled across some issues while working on the click dummy:

In the _"Shard with others"_ section, we actually display the names of users and/or groups we share our files and folders with.

If I share the folder _Books_ with 5 Peeps (as seen below) we come across the likely case that some of the user accepted and some rejected whilst others accepted the share.

I initial idea was to have separate columns and put in those names according to the status. This quickly turned in to a long horizontal list which was not very nice nor was it orderly.

My other Idea leans towards having the same folder in multiple lines if there are multiple states present. As seen below:

| Filename | Status | Shared |
| -------- | ------------------------ | ---------------- |
| :file_folder: Books | | Felix, Marc |
| :file_folder: Books | :hourglass_flowing_sand: waiting for | Otto, Jule |
| :file_folder: Books | :heavy_multiplication_x: rejected by | Karl |
| :file_folder: Music | | Karl, Otto, Jule |
| :file_folder: Movies | :heavy_multiplication_x: rejected by | Karl |

Is that the way I should pursue in your opinion(s)?

@felixheidecke I think we don't need this for "Shared with others". Or if we want to display something, we could change the text behind "Shared" to say something like "2 pending, 3 accepted".

I still wonder whether the sharer should really know anything about whether shares were accepted or rejected. If yes, then we might also need to add an indicator for each user in the share panel. And for group shares in the share panel, also display something like "2 accepted, 3 pending" or so.

Also consider that so far a user could never know how many members a group has. Adding numbers would make it possible to reveal this new information to users. Not sure if we could do that.

For now I'd suggest to go with a simpler change and only adjust the "Shared with you", considering that without this part we cannot continue implementing the feature as it will have a UX hole.
The "Shared with others" is more of a nice to have for later.

True … I build this on the assumption it was the other way around.

only for "Shared with you" section, no change in "Shared with others" for now

What a couple of holidays can make me forget things :-|

forget things

this is why we strive to write everything down in a timely fashion, so no one needs to remember everything and be context-switch safe

Well … it was written down … on 20 Dec 2017 :-|

Implemented in https://github.com/owncloud/core/pull/30106, backport pending

@jvillafanez please close once the backport https://github.com/owncloud/core/pull/31613 is merged

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rehoehle picture rehoehle  Â·  4Comments

jvillafanez picture jvillafanez  Â·  4Comments

michaelstingl picture michaelstingl  Â·  3Comments

dpeger picture dpeger  Â·  3Comments

jnweiger picture jnweiger  Â·  4Comments