Sharing an Item Within a Document, Not Entire Document

HTHawks · February 14, 2020, 8:26pm

I’m going to chime in on Alex_Avenarius thread here (thank you for posting, and for your reply Erica).

@Erica, I am wondering if the Trello card is mislabelled , since technically “ListItem Sharing” is already implemented, but “Explicit listiem sharing” is the topic of concern here?

If it is the correct Trello card, I would encourage others who want this to please be sure to vote for it there if your interested! Trello.

======================
@DEVS -technical challenge?:
I understand from general discussions on the board that “Explicit ListItem Sharing” (as I will refer to it herein) still may be a tall order for the Dynalist project …yes? If I were to guess I’d say the reason seems to be EITHER because of the current method employed for forming ListItem Hyperlinks (i.e. related to “/#=” used for those ) and server platform, AND/OR because handling locking out access to Parent/Ancestor Host Documents is technically counterintuitive to how its setup to work now?
I wonder if “Expiry Link generation” (if employed) would “happen” on another layer and possibly facilitate a solution? Unfortunately I don’t know anything about the development platform and server-hosting, so I really don’t know what I’m talking about -just tossing questions and ideas out in case it could be helpful.

======================
Well I want to throw in my 2-sense Why I think “Explicit ListItem Sharing” seems significantly important for anyone working with other people. (@Moderator: if this seems like hijacking I apologize and please move it. It simply seemed more appropriate to not create yet another thread on this subject.)

So, because this is a little long (I am endeavoring to be detailed and comprehensive [hoping that’s helpful], while also endeavoring to keep focus on simplicity), here are…

Key Points List of this Post

Explicit ListItem Sharing, Expiring Links, and Encryption …potential features entanglement and possible need/value-priority
Identifying Common-Ground Usage Framework, Needs, Concerns, and Limitations (as I see it)
Demonstrating Value: Conceptual Framework + Map of what may be commonly required, followed by Challenge Notes, followed by…
Illustrative Example

#############################################
Topic: Handling a PrimaryConcern/Entity, having multiple Projects, Resources, and People …All Overlapping.

…case review for the importance for being able to Share Individual ListItems Without Exposing the Host Documents (or “Explicit ListItem Sharing”). {with a comprehensive illustrative-Example}

PreNote: Entangled Techincal Concerns: It does well to point out up front that even if Explicit ListItem Sharing feature were provided, there would still exist the encomberment to “permissions access” control due to lack of Expiring/Managed Links feature in Dynalist. I.e., when things change you cannot expire the link and get a new one. I/we don’t know if Dynalist’s serverbase or codebase lends itself to setting this up, and even if it does, don’t know what that may entail.

Personally I would make Explicit ListItem Sharing the priority, i.e., at least have the power of separation from Parent Host material, due to the greater impact it would have on opening this project up to deeper and more flexible usage scenarios where more than one individual is involved (imho).
And I think “Expiring Links” would then be a next priority over “Encryption” for the same reason. Expiring links would lend good protection and facility for changes in people and resources-access control, whereas encryption, while beneficial, actually has lesser scope in these regards, and takes more effort to manage.
Just my 2-sense here.

----- IN A NUTSHELL ------------
So let me begin by saying that I still have yet to learn more about Dynalist’s features, so there may be something I am overlooking here (that would be more helpful toward controlled sharing solution). All I know right now is you can make separate Docs, but that kind of breaks elegant organization and also relationships management.

What I mean by that is… say I have 3 Docs. It seems I can tag them up and explicitly share each one. If I have to connect two of them, I can post cross-links. But then, if I need to be crosslinking to any subListItems, I’ve just exposed the whole Host Doc. Not to mention as this progresses tag management becomes more and more tedious. If I then further break out more Docs, stuff becomes unweildy and messy …so this is simply not working.

• Common Situational Framework: I think most busy environments could be looked at as having these essential aspects…

I. Principle Concerns/Entities, each with multiple
- A) Projects,
- B) Resources/Aspects/Disciplines, and
- C) Trades/People/Crews/Groups.
- D) Locations and Times
  …so this is the scheme I am using for illustrative purposes here.

• Requirement: Discreetly/Explcitily Share a ListItem with someone(s) {associate persons or groups} where:

That/Those someone(s) may change.
That/Those someone(s) may be involved in different project aspects at various times, and
In some cases at more than one locale, or Zones at a Locale,
So they may require access to various ListItems, but without carte-blanche full access to a locale’s tasks or resource’s or other related stuff/data (i.e., full document or other documents).
(Concept Framework and Example, and then a working Example appear below)

• Concerns and Limitations
Dynalist limitations I am running up against for this application are:
a) sharing a ListItem exposes everything in the host document
b) crosslinking to another ListItem in another document exposes everything (all other list items and linked items) in the other document(s) as well
c) Tagging instead of linking does not connect Document spaces’ ListItems when sharing only one of the documents (actually a Desireable feature in most regards),
d) some cases you want to use folder and multiple document management and others you may not want to, so… This functionality has its place for organizational management, not necessarily for controlling sharing permissions, and seems best determined by the user’s “brainscape” and not by a sharing management or other app limitation.

Additional problem I see is that, even if ListItem sharing is implemented, as relationships change, you cannot refresh/change/Expire Links for ListItems or docs, so link management is a related (potentially huge) challenge considering the sort of application being addressed here (which I would think would be quite common actually).

Related to this is Tag Breaking: while searching Same Named Tags in different documents can be performed by, and is helpful for, the list author, 1) this is not the case for shared documents and 2) if at some point you wish to change a tag, if you are forced to use many documents for a project concern, then you have to change/update each same-named tag in each document case.

=========================================================
CONCEPT EXAMPLE - Framework & Map (framework here is fictional, as my actual application is a bit more complicated, but framed-relationships accurately apply…)

•CONCEPT FRAMEWORK
Concern1 (an Entity) has

projects going on
at each of Locale1, Locale2, Locale3, Locale4, etc
…and then…
various Tradespeople handling
various Aspects (Disciplines) like say …glass, wood, metal, paving, steel, water, security, automation, etc, AND/OR managing Zones at Locales
…AND THEN…
there may be various Aspect Handlers depending upon what Locale, so for instance, wood-tradespeople1 handling Locale 1 + 2, but wood-tradespeople2 handling the other Locales, or Locale Zones. There may even be slight overlap to handle.

Don’t worry, it should become simply clear later in the example, this is a fairly standard demograph…

•CONCEPT MAP -4 Pillars
Example of General Tagging and Organization Structure (similar to what I have at this very infant stage of everything) looks like this:

PrimeConcernDOCUMENT (<–a Dynalist Document)
PrimeConcernDocument SECTIONS

“People Keep 'em spinning”: for daily/periodic tracking with agents
“People Tasks Tracking”: for tracking tasks under explicit stewardship by specific entities
“Locales / Zones Tasksheets”: for filling out and tracking explicit project zones’ needs+conerns
**…**and then they are all readily interlinked primarily using tags

TAGGING
Tag Group A: TIME stuff, like #Now, #Today, #Later, etc
Tag Group B: TRADES/PEOPLE: @AdamA, @BarnyB, @ConnieC, @DavidD, etc
Tag Group C: LOCALES: #Locale1, #Locale2, #Locale3, #Locale4, etc, (then there may be Zones as well)
Tag Group D: DISCIPLINES: #Glass, #Wood, #Steel, #Rock, #Cement, #XYZSystems, #XYZResources, etc
(Note: Those tag formats are morphing with multi-prefix assignments, but I’m not addressing that here. I’m trying to keep this real simple and straightforward [believe it or not]…)
FILTER~SEARCH Example (the reveal/demonstration):
Posted separately next, due to its length.

Challenge Notes:

Not everyone in Locale1 is supposed to have access to everything else going on there, however, I need to manage everything there “as one”. As well,
Some aspects of various Locales’ Projects intersect or overlap,
Not everyone dealing with a discipline, say Wood/Carpentry, is supposed to have access to all things Wood related, and
Some people work on one or more projects (per a specified discipline) in various locales and some do not,
Some people work on one or more disciplines at various Locales and not others.
Some people have greater oversight in areas than others.

======================
Maybe a little confusing without an example, I know. The Filter~Search Example below (in the next post) should hopefully make clear why I identify this structure as fairly common (“simply”, I hope),

Dynalist offers a most liberating potential solution for managing project lists and tracking with “multi-faceted focus” with either the Concern, Locales, Resources and/or People involved. I find the tag-filtering system, and general organization, offered by the Dynalist project to be fairly matured, and the simple interface, but depth of features, --is very accommodating in many ways–, making this an exceptional tool. With explicit listitem sharing and some expiry linking I think this would jump light years ahead of the present market footing. (?)

If I understand correctly (from other discussions), the expiry-linking concerns mentioned above may not be able to be addressed in the near future(?). For a User To overcome expiry-link limitations I think one can copy everything into a new document, and then you have to tend to broken links. For smaller project concerns it may be worth it. Unfortunately sustainability is limited in a more weighted work environment.

If I had to choose I would live with the expiry-linking limitations concerns and push for explicit linkitems sharing (not exposing whole documents for the sake of a shared subitem).
For now it seems I would need to manually update people with exported copies or something similar =>work I was hoping to use Dynalist to avoid ;^).

Refer to the Filter~Search example below in the next thread (simple walkthrough).

==============
I hope the above explanations provide some useful insight and may be helpful to further discussions on this concern. Please vote this up at the Trello if this interests you.

PLEASE VOTE! Share individual items on Dynalist Roadmap | Trello -