- If attachment exists at same relative path in new base directory,
leave it alone so that it continues to work.
- If attachment doesn't exist in new base directory, revert it to an
absolute path.
- If new base directory is an ancestor or descendant of the previous
base directory, adjust relative paths below the new directory so that
they keep working.
- More dialog changes
- Select current base directory in file picker when changing directory
- Always use .persistentDescriptor instead of initWithPath(), though it
probably doesn't matter, and wrap in try/catch in case the old setting
is broken in some way.
- New function Zotero.File.directoryContains(dir, file), since
nsIFile.contains() isn't recursive
- Don't use a private Zotero.Item property from outside to force path changes.
- Changed placeholder to just "attachments:" for consistency with "storage:"
- Reworked dialog text
- Use a fancier (and undocumented) filefield XUL element for path
- A few small code tweaks
Translator updates and broken translator reporting both make automatic
requests to zotero.org, but the version pref is just adding a header
with the Zotero version on existing requests.
With any storage service backed by S3 or another eventually consistent
storage service, there will be a short delay between when files
are uploaded and when they're available, so show a more helpful message
and allow the verification to pass. (Any IIS servers configured not to
serve extensionless files will also fail, but that's probably much
rarer at this point.)
We should also just retry the request on a 404, but that will have to
happen on master.
Addresses #115
beginUpdateBatch() doesn't suppress select events, so various batch
operations were triggering lots of extra selects.
This hopefully fixes the long hang some people were seeing when making
changes with an open quick search (which I was only able to reproduce in
Standalone).
- Some item changes were putting data in the wrong form into extraData,
which was keeping it from being passed through in notifications.
- For item modifications, set a 'changed' object, keyed by itemID, with
just the fields that changed as keys and their old values. For
deletes, keep the 'old' object for now, since sync relies on it.
- Remove item.serialize() for all item changes except deletions, which
should speed up writes (and which will leave extraData empty for some
changes).
- Currently only item fields, creators, related items ('related'), and
'parentItem' are added to 'changed'.
Closes#220
