I have many lists and many editors.

I have many lists and many editors. One editor has sharing permission on maybe 25% of the pages, and I want to let him share the rest.  There's no easy way to see what he's shared on and what he isn't. Am I safe just selecting all lists in List View, and adding him as a share to all? That will be a little illogical, since he's already sharing 25% of them. Am I safe to do this?

Comments

  1. Hello Jim, the answer is yes, you're safe to do it. The person will get notification that they get access to new lists only.

    ReplyDelete
  2. Thanks.

    I did it, and the sharing changed the modification dates for all my lists to "today". So I can no longer see which lists have been worked on most recently.

    There is no reason for a sharing action to affect the modification date of a list.

    ReplyDelete
  3. Sorry that this made a problem. Technically, list update timestamp was updated because there was an activity on the list (and changing list sharing information is considered an activity in Checkvist, as well as changing list options).

    ReplyDelete
  4. This is a little bit crazy. Administrative changes like this should not affect update timestamp.

    I can imagine special circumstances where people might want this, but I'm sure it's not expected or desired behavior for most customers, who will naturally expect timestamp to update only for edits to actual list content.

    ReplyDelete
  5. I agree with you, this is not expected for most customers. But, you're the first person who noticed this problem and wrote us about it. We might introduce an additional timestamp field which would update only if list items content changes, this makes perfect sense.

    I've added this request to Uservoice: http://checkvist.uservoice.com/forums/2121-general/suggestions/12294255-add-a-real-list-modification-timestamp-which-updat

    ReplyDelete
  6. Thanks, Kirill. But if you agree this shouldn't be default behavior, why not remove this behavior rather than introduce the (significant) complexity of a second timestamp?

    ReplyDelete
  7. Because we anyway need a timestamp which reflects any change related to the list data or its options or sharing settings, internally. Otherwise cache update mechanism might be broken.

    ReplyDelete
  8. Ok, so the "second timestamp" you are considering adding would be the only timestamp from the user perspective? If so, that sounds great. If not, the complexity would a problem for us and for you, both!

    ReplyDelete

Post a Comment

Popular posts from this blog

Hello friends

Hello friends!