Patch for disabling libraries

[mronkko]

I have developed a patch that implements enabling and disabling libraries. 

Libraries are disabled and enabled using context menu in the collectionTreeView in the Zotero client. Here is a screenshot

http://imageshack.us/photo/my-images/855/screenshot20110827at182.png/

When a library is disabled, it disappears from the word processor plugin. This means that

1) The classic insert citation does not show this library anymore 

2) Any items inserted previously from a library that is now marked disabled are considered missing and the word processor plugin will ask for a replacement

The use case for this is ensuring that when working with other people that you share a group library with, the all the citations in the document are only from the group library.

Looking forward to any comments.

[Dan Stillman]

Keep this in the forums for now, since I think this requires further
discussion.

http://forums.zotero.org/discussion/19350/option-to-disable-libraries/#Item_6

[Mikko Rönkkö]

Here is a better patch. It extends the functionality of disabling a library in the following ways

1) A disabled library is always collapsed in the user interface and would not show any items inside the library
2) A disabled library cannot not be used as a target for drag and drop
3) Trying to import items into a disabled library or in any other way to make changes to the library results in the same error prompts as read-only libraries
4) The only context menu item for a disabled library is "Enable" so that the library must be enabled before any other actions can be done
5) The tags are not shown for disabled libraries in the tags selector
6) Disabled libraries cannot be searched

Mikko

[Bruce D'Arcus]

2011/8/28 Mikko Rönkkö <mikko....@iki.fi>:

> Here is a better patch. It extends the functionality of disabling a library in the following ways

I haven't followed this, but on first glance, the whole premise of
this is really confusing. The verb "disable" doesn't really make sense
to apply to the entire "library"; it seems to apply instead to
syncing.

So for sake of argument, why not just add some configuration logic to
the sync preferences?

Either way, you need to make this more clear in my view.

Bruce

> 1) A disabled library is always collapsed in the user interface and would not show any items inside the library
> 2) A disabled library cannot not be used as a target for drag and drop
> 3) Trying to import items into a disabled library or in any other way to make changes to the library results in the same error prompts as read-only libraries
> 4) The only context menu item for a disabled library is "Enable" so that the library must be enabled before any other actions can be done
> 5) The tags are not shown for disabled libraries in the tags selector
> 6) Disabled libraries cannot be searched
>
>
>
> Mikko
>
>
>

>> --
>> You received this message because you are subscribed to the Google Groups "zotero-dev" group.
>> To post to this group, send email to zoter...@googlegroups.com.
>> To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
>>
>
> --
> mikko....@iki.fi
>
> tel: +358 50 387 8155
> skype: mikko_ronkko
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> To post to this group, send email to zoter...@googlegroups.com.
> To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
>
>
>

[Mikko Rönkkö]

On Aug 28, 2011, at 17:03, Bruce D'Arcus wrote:

> 2011/8/28 Mikko Rönkkö <mikko....@iki.fi>:
>
>> Here is a better patch. It extends the functionality of disabling a library in the following ways
>
> I haven't followed this, but on first glance, the whole premise of
> this is really confusing. The verb "disable" doesn't really make sense
> to apply to the entire "library"; it seems to apply instead to
> syncing.

> So for sake of argument, why not just add some configuration logic to
> the sync preferences?
>
> Either way, you need to make this more clear in my view.

The patch does not affect sync at all. What is does is disable a library from the user interface, makes it read-only, and prevents using the items in the word processor plugins.

My use case for this is the following. I have the personal library and 4-5 group libraries that I use. Typically when I work on a paper, I just want to use one or maybe two libraries. I want to disable the other libraries to ensure that
1) I will not accidentally import an item to a library that I am not currently working with
2) I will not accidentally add items that are in a library that I do not want to use for the paper that I am currently writing
3) I want to be warned If an item outside the chosen libraries is included in the paper if I copy-paste content from my other papers

This addresses three problems
1) Citations in a document that are in libraries that are accessible to coauthors "break" Zotero for coauthors. This is particularly frustrating if the coauthor is new to Zotero because this makes them think that Zotero does not work for them.
2) Duplicate items in a document when the same item is included from multiple libraries.
3) Not knowing in which library to look an item whose information needs to be corrected

It would make sense that disabled libraries are not synced, but I this is not addressed in the patch.

Mikko

[Bruce D'Arcus]

On Sun, Aug 28, 2011 at 10:20 AM, Mikko Rönkkö <mikko....@iki.fi> wrote:
>
> On Aug 28, 2011, at 17:03, Bruce D'Arcus wrote:
>
>> 2011/8/28 Mikko Rönkkö <mikko....@iki.fi>:
>>
>>> Here is a better patch. It extends the functionality of disabling a library in the following ways
>>
>> I haven't followed this, but on first glance, the whole premise of
>> this is really confusing. The verb "disable" doesn't really make sense
>> to apply to the entire "library"; it seems to apply instead to
>> syncing.
>
>> So for sake of argument, why not just add some configuration logic to
>> the sync preferences?
>>
>> Either way, you need to make this more clear in my view.
>
> The patch does not affect sync at all. What is does is disable a library from the user interface, makes it read-only, and prevents using the items in the word processor plugins.
>
> My use case for this is the following. I have the personal library and 4-5 group libraries that I use. Typically when I work on a paper, I just want to use one or maybe two libraries. I want to disable the other libraries to ensure that
> 1) I will not accidentally import an item to a library that I am not currently working with
> 2) I will not accidentally add items that are in a library that I do not want to use for the paper that I am currently writing
> 3) I want to be warned If an item outside the chosen libraries is included in the paper if I copy-paste content from my other papers
>
> This addresses three problems
> 1) Citations in a document that are in libraries that are accessible to coauthors "break" Zotero for coauthors. This is particularly frustrating if the coauthor is new to Zotero because this makes them think that Zotero does not work for them.
> 2) Duplicate items in a document when the same item is included from multiple libraries.
> 3) Not knowing in which library to look an item whose information needs to be corrected

I totally agree with the substance of the usability issues you
identify, but wonder if there are other ways to address them?

E.g. you're solution still requires manual work on the part of the
user, and seems like it doesn't entirely solve the problems. I'd
ideally like something that involved less conscious user work.

I have a suspicion, for example, that Zotero could be made smart
enough to automatically avoid your problem cases #2 and 3.

Consider, too, the case I've been harping on for years, but is close
to being solved: three users collaborating on a document, one of whom
uses Mendeley.

Couldn't we have a solution that addresses all of these?

Bruce

[Mikko Rönkkö]

Number 2 might be addressed by some kind of duplicate detection between libraries. However, this is not without issues. If one of the items were edited, would the other one also be changed or would they stop being duplicates?

#3 could be solved by adding a new button to the word processor plugin that would show the selected citations in Zotero. This would be easy for single item citations, but complicated for citations with multiple items.

Yet other concern is that I sometimes have accidentally a wrong library selected and import articles that others have little use into a group library or cannot find the item when I am citing it because it went to a wrong library.

Enabling and disabling collections would be an easy solution to these problems.

>
> Consider, too, the case I've been harping on for years, but is close
> to being solved: three users collaborating on a document, one of whom
> uses Mendeley.

>
> Couldn't we have a solution that addresses all of these?

I have never used Mendeley nor have written anything with Mendeley and cannot really comment on this issue

Mikko

[Dan Stillman]

This discussion doesn't belong on this list, which is for technical
development issues. Backing up an idea with a working patch is great,
but I have no intention of incorporating this patch as it is, as I
remain unconvinced that it's the best way to address the issues
identified (or even that they're all worth addressing). Until that
changes, this discussion should remain in the forums, where there's
already a thread for it and where a much wider audience can participate.
Posting here just breaks up the discussion and makes it harder to follow.

http://forums.zotero.org/discussion/19350/

[Mikko Rönkkö]

I had never thought that this would be accepted as it is. There can be other better solutions or better way to implement this solution.

Let's continue the discussion at the forum.

Mikko

On Aug 28, 2011, at 18:30, Dan Stillman wrote:

> This discussion doesn't belong on this list, which is for technical development issues. Backing up an idea with a working patch is great, but I have no intention of incorporating this patch as it is, as I remain unconvinced that it's the best way to address the issues identified (or even that they're all worth addressing). Until that changes, this discussion should remain in the forums, where there's already a thread for it and where a much wider audience can participate. Posting here just breaks up the discussion and makes it harder to follow.
>
> http://forums.zotero.org/discussion/19350/
>

[Mikko Rönkkö]

Hi

Here is a patch that implements the "preferred library" approach described in this post http://forums.zotero.org/discussion/19350/option-to-disable-libraries/#Item_24

What it does:

-Adds two new document level preferences: usePreferredLibrary (checkbox) and preferredLibraryOrCollection (a library or collection chosen using the collectionTreeView tree)

-Splits the document preferences window into tree tabs to make it more compact

-When a preferred library or collection is chosen and enabled all items that are added to the document will be automatically copied to this library and assigned to this collection

-QuickFormat bar pulls items from only the selected library and collection

Here is a screen shot of the preferences window after the modification http://imageshack.us/photo/my-images/651/screenshot20110831at225.png/

Potential user level issues in the patch:

-A document with a preferred library can automatically share items to a group library, so there might be a need for some kind of notification about this to avoid potential privacy issues. Or there could be a preference in Zotero that disables automatic sharing of items to group library.

-QuickFormat does not pull items from child collections if a preferred collection is set (At least I did not implement this intentionally.)

-If a preferred library is set to a collection under my library, this will most likely be linked to a wrong collection if the document is shared with someone else because the collection IDs within my library are probably not unique between installations. This could be solved by disabling preferred library for my library or storing an identifier with the document (e.g. Zotero user ID or the ID of the firefox profile if the Zotero user ID was not configured) and only apply the preferred library if the document was edited with the original user. (It would of course be possible to also add different preferences for different users based on the ID.)

Technical issues

-There is some SQL in the user interface layer code. This could be replaced with data layer functions

-I copied some code from other functions. These could be easily refactored, but I wanted to make minumum changes to the existing code. I have marked these with TODO comments

I have tested this some, but not very thoroughly. It seems to work for me.

Mikko

[Simon]

Can you post this on gist.github.com? Google Groups strips all the whitespace (when viewed online, at least).

[Mikko Rönkkö]

https://gist.github.com/1184649

On Aug 31, 2011, at 23:35, Simon wrote:

Can you post this on gist.github.com? Google Groups strips all the whitespace (when viewed online, at least).

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/zotero-dev/-/V-M1uK-aDO8J.

To post to this group, send email to zoter...@googlegroups.com.
To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.

[mronkko]

On Aug 31, 11:38 pm, Mikko Rönkkö <mikko.ron...@iki.fi> wrote:
> https://gist.github.com/1184649

Any comments on this patch to allow the user to select a preferred
library? Are there any changes that it might be included in the next
version of Zotero? Let me know if there are any issues that would need
to be fixed.

Mikko

[Simon]

We'd like to include this in 3.0, but we want to refine/refactor a few things in other parts of the Zotero codebase in order to avoid redundant code. We'll give another update soon.

Simon

On Wednesday, September 7, 2011 11:22:48 AM UTC-4, mronkko wrote:

[mronkko]

On Sep 8, 8:48 pm, Simon <si...@simonster.com> wrote:
> We'd like to include this in 3.0, but we want to refine/refactor a few
> things in other parts of the Zotero codebase in order to avoid redundant
> code. We'll give another update soon.

Great. Please let me know if there are any issues with the patch or if
you need help with it. Also, I would be happy to test the patch once
it is included in the trunk.

Mikko