I have searched for this request to have been made earlier, because I canât believe Iâm the first one to request this, but havenât exactly found it.
So, please make it possible to share an individual item within a document in the same ways itâs possible to share a document. I understand Workflowy supports this, but Dynalist does not.
Thatâs inconvenient. Right now, if I wish to share a portion of my document, I need to extract the item(s) from the document so that it becomes a separate document. Then I need to link back to it from the original document⌠Itâs time-consuming and inconvenient.
ALex_Avenarius, I am struggling with this as well.
Be mindful, anytime you linkback to another document you expose them both to access by the person you shared one to.
So when sharing DocB, a link back to DocA gives them access to it.
What I am going to try to do is rely on tags rather than links for cross connecting where I need to, BUT the problem is I may need the person with DocB access to also have access to something that must live in DocA domain.
I am working up a followup post for later with details for folks to review, and to see if thereâs more interest (to prompt) in voting on thisâŚ
Share individual items on Dynalist Roadmap | Trello -
Thank you for your initiative on this, HTHawks! This is definitely one of the top âmissing featuresâ in Dynalist, and it especially compares negatively with Workflowy where sharing individual items of a list is highlighted as one of its top features to prospective customers⌠And no wonder â I would find it very useful on a daily basis, because I collaborate with lots of folks.
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?
====================== @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.
Before I address your other points (might take a while, sorry!), may I quickly ask what do you mean by âListItem Sharing is already implementedâ? Thereâs currently no way to share it if itâs not the root item of a document. Did you mean you can send them a link to a specific item, while sharing the entire document?
FILTER~SEARCH METHOD & RESULT / WORKING EXAMPLE (related to my above post)
Here I will try to illustrate what I think would be a typical application employing an outliner for project elements tracking, and the case for Exclusive ListElement Sharing (exclusive meaning sharing it wonât lend full access to the host document for the sharee).
Disclaimer: I am not an ace at GTD or related methods. My organizational approach is still very much a work in progress. As well, other related List aspects are not on display here (InBox, etc). That said, Please feel free to comment on anything.
FRAMEWORK
**Main Doc: **
PrimeConcernDocument Sections (the main Dynalist Doc for this example) Primary Sections I-III
"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
Tags Setup
Tag Group A: TIME stuff, like #Now, #Today, #Later, etc
Tag Group B: TRADES/PEOPLE: @AdamA, @BarnyB, @ConnieC, @DPeople4 to ZPeople26, etc
Tag Group C: LOCALES: #ALocale1, #BLocale2, #CLocale3, #DLocale4, etc, (then there may be Zones as well)
Tag Group D: DISCIPLINES: #Glass, #Wood, #Steel, #Rock, #Cement, #SecurityItem1, #SecurityItem2, #ElectricalResource1, #ElectricalResource2, etc, etc
(Note: Those tag formats are morphing with multi-prefix assignments, but Iâm not addressing that here.)
====================================== Example Filter~Search Criterion Brief description of this âworkingâ example filter: Iâm targetting a couple prime people working project aspects at 2 locales. One of the locales has 2 zones. Other people are involved in work at these locales. I want a quick overview of anything relevant to the two people/groups in question, with relation to #ALocale1, including anyone else tangentally engaged in job aspects with them there, AND I also then want a summary on #ALocale1 lists at the end.
======================================
The resulting list structure weâre after will resemble something like:
PrimaryConcernHavingManyProjects (doc)
People Keep 'em Spinin
@AdamA -call for things today
@BarneyB -call for things today
People Tasks Tracking
@AdamA
things to do
#ALocale1 things to do
@BarneyB
things to do
#ALocale1 things to do
@ConnieC
things to do per @AdamA or @BarneyB
Locales / Zones Tasksheets
#Alocale Tasklist
Stuff @AdamA is working on
Stuff @BarneyB is working on
Stuff being done elsewhere that is specifically related ======================
Filter~Search Looks kinda like: ancestor:#ALocale1 -ancestor:#BLocale2 -#BLocale2 OR #ALocale1 -ancestor:#BLocale2 -#BLocale2 OR ancestor:@AdamA -ancestor:#BLocale2 -#BLocale2 OR @AdamA -ancestor:#BLocale2 -#BLocale2 OR ancestor:@BarneyB -ancestor:#BLocale2 -#BLocale2 OR @BarneyB -ancestor:#BLocale2 -#BLocale2
NOTE: I have limited the search criteria in the example, which is intended to be illustrative, and which technically might should include consideration for excluding other Locales.
Filter Logic Explanation: Because Locales 1+2 have intertwined concerns, and with the people in question as well, I need to use some separation in the filter logic, soâŚ
::Get locale 1 stuff, i.e., anything tagged locale1 or with it as its ancestor, but minus the Locale2+ stuff:
ancestor:#ALocale1 -ancestor:#BLocale2 -#BLocale2
OR #ALocale1 -ancestor:#BLocale2 -#BLocale2
::Get group1 stuff, i.e., anything tagged group1 or with them as its ancestor, but minus focus on any of their work going on in Locale2:
OR ancestor:@AdamA -ancestor:#BLocale2 -#BLocale2
OR @AdamA -ancestor:#BLocale2 -#BLocale2
::Get group2 stuff, i.e., anything tagged group2 or with them as its ancestor, but (again) not focussing on any of their work going on in Locale2:
OR ancestor:@BarneyB -ancestor:#BLocale2 -#BLocale2
OR @BarneyB -ancestor:#BLocale2 -#BLocale2
Note1: Some #BLocale2+ stuff may still appear due to deep entanglements, but the focus will remain prominently on the desired objective -these two guys/gals/groups and Locale1
Note2: All references to an ItemX in this case include calls to both ancestor:ItemX and ItemX, but this is, obviously, not always the case. The ancestor feature in Dynalist provides flexibility in how one might employ ancestor vs individuated tagging -not uinder discussion here, but important to note.
======================================== Results -And so here we go. This is based on a realworld example, but with a totally ficitious framework.
===================================== PrimeConcernDocument
. . note: I am not showing the whole document anywhere, only its conceptual structure map has been identified, and then this filter-result example.
I. PEOPLE KEEP 'EM SPINNING -DAILIES -TERSE LIST
Result: list limited to people in the filter call. I can immediately see whats on the front burner with the two people in question:
@AdamA- call per ruksor completion due in 1 week
sheâs gotta followup on the XY Frame layout first
(entry hidden) something to do with #BLocale2
sheâs flyin out to #CLocale3 on Wed (and this would be hidden as well if filtered same as #BLocale2)
@BarnyB- set plan shed on track4
=====================================
II. PEOPLE TASKS TRACKING BREAKOUT
Result: list based on people and their work at Locale1 per the filter call, minus their tasks at Locale2 (except for incidental entanglements, so then will pull in other relevant people and locales where intersections exist [hence @ConnieC below]). Gives me a good overview from a âworking-crews perspectiveâ, with focus on the relevant responsibilities of the primary people in the Filter-Query focus.
@AdamA (contractor) - ref on plan trak in proj2 book
-remove Carl off term p #ALocale1
followup on glassB frameW
[entry hidden] elect extension for R-term #BLocale2
needs to follow on new secsys co #CLocale3 [maybe hidden if #CLocale3 also filtered on]
(entry hidden) a description on thing to do with #BLocale2
another descrip per #CLocale3 in general [maybe hidden if #CLocale3 also filtered on]
@BarnyB (contractor) - set plan shed on track4
Get #Flocale6#zoneX factor3 in order [maybe hidden if locale or zone filtered on]
start working plan for sub-section A, must review with @PersonZ (owner)
#ELocale5 replacements need substrate comp [maybe hidden if locale filtered on]
ask about the new *#zoneV [maybe hidden if zone filtered on]
@ConnieC (controller) - ::trak/report
#ALocale1 Bus and Auto+Sec System budget review
=====================================
III. LOCALES / ZONES TASKS
Result: list based primarily on relevant Locale(s) in the filter call. So below the above trimmed down work-crew overview I then get here an overview of the relvant Locale(s) / Zone(s).
#ALocale1 (from the Filter Query)
#ZoneT
@AdamAand@BarnyB Access changes
more sub stuff
more sub stuff
@BarnyBand@DPeople4 meet routing when ADelta met
more sub stuff
more sub stuff
2ndary storyboard on Elecy
Sub1 stuff
more sub stuff
Sub2 stuff
more sub stuff
#ZoneYY (another zone in ALocale1)
@ZPeople26 and @BarnyB Delta Bravo
more sub stuff
more sub stuff
@BarnyB and @XPeople24 conf post #DeltaB
some sub stuff
Transfer over to #ZoneB
Sub1 stuff
more sub stuff
Sub2 stuff
more sub stuff
#BLocale2+ [any jobsites without reference to one of the people on the filter will be suppressed, but if one of them has related work at an otherwise excluded site, that list item will be displayed
Send updated sitemap to @BarnyB
subnotes
[all other entries for site are hidden (not relevant)]
==================================
WITH EXPLICIT LISTITEM SHARING ONE COULD SEND AdamA or BarneyB A LIST RELEVANT ONLY TO THEIR WORK THAT AUTO UPDATES.
WITH EXPIRING LINKS, ONE COULD HAND OFF AUTHORITY TO SOMEONE ELSE, AND/OR RETIRE AUTHORITY ALTOGETHER (but right not you cannot change the link or access to it -big problem!)
##############
I hope this conceptual description and example are useful in providing prime insight into
how powerful Dynalist can be for quickly bringing focus onto a multiplicity of aspects of an explicitly extracted areas of a broad job/concern âŚthat exists within a deeply diverse host-concern having many jobs. AndâŚ
how valuable a tool Dynalist can be for doing this, AndâŚ
how much greater value it would have if ExplicitListItem Sharing, as well as Expiring Links were onboarded (game changer).
Thank you for you interest.
Thank you Dynalist team for the inspiring project.
Twohawks
Right, no way to do that right now. And Iâm missing that feature every day. For example, weâre hiring a web developer for a one-off project right now, and instead of me being able simply to share my notes and instructions with him from within my main Dynalist doc, I first need to transfer those notes to a separate new doc before I can share them with him and others. Quite a runaround.
And yes, @HTHawks, Iâm aware I can only use internal Dynalist links from a private doc/item to a shared one, but not vice versa, because that might expose my private content to anyone clicking the link. Itâs definitely a risk unless you pay attention to what youâre doing.
In any case, thank you, @HTHawks, for approaching this feature request in such a thorough, scholarly manner! I think we can all agree that this is a feature that we may reasonably demand from Dynalist, given that itâs one of the âshowcase featuresâ for Dynalistâs competitor WorkFlowy. (And I kinda automatically expect Dynalist to be ever-so-slightly better than WorkFlowy in every aspect.)
Yes, @Erica, I meant you can get a link for any ListItem and send it to someone, but then they have access to the Parent Document from there.
I TOTALLY Appreciate it is some long-a$$ stuff I posted, and will take some time for any review and consideration.
I wanted to be sure to make a comprehensive case and back it up. The case is, people deal with projects, sometimes having multiple aspects, then you have people, things, places, and time.
The filter-search example demonstrates how, even in a seemingly unweildy and complex depth of a situation, Dynalist is the sort of tool one could use to tackle tracking effectively, but then sharing adds another set of complexities.
I figured it does well to break it down to see just what that may look like âŚin case it helps tie these conceptual concerns together. (and to illustrate the potential value for consideration)
Features - Dynalist Forum
I think we can all agree that this is a feature that we may reasonably demand from Dynalist, given that itâs one of the âshowcase featuresâ for Dynalistâs competitor WorkFlowy. (And I kinda automatically expect Dynalist to be ever-so-slightly better than WorkFlowy in every aspect.) 