{ "info": { "author": "SENAITE Foundation", "author_email": "hello@senaite.com", "bugtrack_url": null, "classifiers": [ "Framework :: Plone", "Framework :: Zope2", "Programming Language :: Python" ], "description": ".. image:: https://raw.githubusercontent.com/senaite/senaite.core/master/static/logo.png\n :target: https://github.com/senaite/senaite.sync\n :alt: senaite.sync\n :height: 128px\n\n*Data Synchronization tool for SENAITE LIMS*\n============================================\n\nSENAITE.SYNC is a SENAITE add-on to synchronize data amongst SENAITE instances\nor migrate from a BIKA instance.\n\n\nInstallation\n============\n\nIn order to get SENAITE.SYNC running properly both `senaite.api` and\n`senaite.jsonapi` are required in the source and destination instances.\nHowever, `senaite.sync` is only required in the destination instance (where the\ndata is to be imported).\n\nReady-to-go Installation\n------------------------\n\nWith this installation modality, the sources from `senaite.sync` will be\ndownloaded automatically from\n`Python Package Index (Pypi) `_.\nIf you want the latest code from the\n`source code repository `_,\nfollow the installation instructions for development listed in the next section.\n\nTo install SENAITE.SYNC, if you are already using `senaite.lims`, you simply\nhave to add `senaite.sync` into the `eggs` section of your `buildout.cfg`::\n\n eggs =\n ...\n senaite.sync\n\n`senaite.lims` already installs `senaite.jsonapi` and `senaite.api` for you. However, if you are only using `senaite.core` you should also add `senaite.jsonapi` and `senaite.api` as dependencies. Hence, the `eggs` section\nof your `buildout.cfg` should look like::\n\n eggs =\n ...\n senaite.sync\n senaite.api\n senaite.jsonapi\n\nFor the changes to take effect you need to re-run buildout from your console::\n\n bin/buildout\n\n\nNote\n~~~~\n\nThe above example works for the buildout created by the unified installer. If you are using a custom buildout file for SENAITE, as `suggested when installing `_ `senaite.health`, you should then add the eggs to the `eggs` list in the `[instance]` section rather than adding it in the `[buildout]` section.\n\nThen build it out with your custom config file::\n\n bin/buildout -c .cfg\n\nAlso see this section of the Plone documentation for further details: https://docs.plone.org/4/en/manage/installing/installing_addons.html\n\nInstallation for Development\n----------------------------\n\nThis is the recommended approach how to enable `senaite.sync` for your\ndevelopment environment. With this approach, you'll be able to download the\nlatest source code from `senaite.sync's repository `_\nand contribute as well.\n\nUse git to fetch `senaite.sync` source code to your buildout environment::\n\n cd src\n git clone git://github.com/senaite/senaite.sync.git senaite.sync\n\nCreate a new buildout file, `.cfg` which extends your existing\n`buildout.cfg` \u2013 this way you can easily keep development stuff separate\nfrom your main buildout file, which you can also use on the production server.\n\n`.cfg` should look like::\n\n [buildout]\n index = https://pypi.python.org/simple\n extends = buildout.cfg\n develop +=\n src/senaite.sync\n\n [instance]\n eggs +=\n senaite.sync\n\nIf you are using `senaite.core` and not `senaite.lims` then `.cfg` should look like::\n\n [buildout]\n index = https://pypi.python.org/simple\n extends = buildout.cfg\n develop +=\n src/senaite.sync\n src/senaite.api\n src/senaite.jsonapi\n\n [instance]\n eggs +=\n senaite.sync\n senaite.api\n senaite.jsonapi\n\n\nIf you already have a custom buildout file, replace `buildout.cfg` in `extends = buildout.cfg` by your custom buildout file. Note that with this approach you do not need to modify the existing buildout file.\n\nThen build it out with this special config file::\n\n bin/buildout -c .cfg\n\n\nand buildout will automatically download and install all required dependencies.\n\n\nDocumentation\n=============\n\nThe following sections give some information about the functional side of Senaite\nSync. First we will explain what is the purpose of Sync, what it can be\nused for. Then, we will talk about its configration and in the end a few\nexamples to make it more understandable.\n\nWhat does Senaite Sync do?\n--------------------------\n\nSenaite Sync (SYNC from now on), can be used for 3 different purposes:\nMigration/ Back-up of Instances, Track of Instances (one-way\nsynchronization) and Synchronization of multiple instances. In any case,\ninstallation and configuration are done similarly. While configuring\nSYNC, the user must have a clear idea about his/her needs and do the\nproper configuration. In order to make it easier, let\u2019s define what each\nof these 3 cases mean clearly.\n\nMigration & Back-Up\n-------------------\n\nThis is the most basic use of SYNC. As it is said in its name, it is\njust to migrate instances which can be thought as copying the DB. The\nadvantage of SYNC Migration over just copying the DB files is, that\ncopying DB files can help you only with having the same instance on the\nsame version of Senaite and its Add-ons. However, SYNC is capable of\nretrieving data from an older versions of Senaite (even Bika Lims) and\nbuild the latest version of Senaite Add-ons respecting that data. It is\nvery helpful to avoid running several upgrade steps to update the\ninstance to the latest version. By running SYNC Updates periodically on\nthe destination instance, changes after migration can be handled and\nthis is can be thought as a quick back-up tool of the source instance.\n\nTracking Instances\n------------------\n\nThis case is useful when you have more than one instances working\nindependently and you want to gather all the data in one central\ninstance to use for reporting or another purposes later. It is also\npossible that remote instances share some data but contain their own\ndata as well. In both cases objects can be saved in the central instance\nwith or without Prefixes and easily be distinguished which remote\ninstance they belong to. SYNC Updates are available in this case too.\n\nSynchronization of Multiple Instances\n-------------------------------------\n\nThe last, the most useful and the most complex use of SYNC is this one.\nFirst of all, make sure you understand previous cases since for\nSynchronization, Migration and Tracking are required. Basic\nSynchronization is still easy to configure, but for special cases which\nwe will talk about later, it can require attentive configuration on each\ninstance. Synchronization amongst instances will keep them updated with\neach other\u2019s changes and they can share any part/amount of data\ndepending on users\u2019 wish.\n\nConfiguration Options\n=====================\n\nAs we previously said, configuration is totally about what you want SYNC\nto do. Let\u2019s have a deep look at each of configuration fields and their\nmeaning. Bear in mind that we are not configuring any Remote yet, this\nchapter contains information only about the meaning of the configuration\noptions.\n\nRequired Configuration\n----------------------\n\nThere are some required fields that without them SYNC cannot be used at\nall. They are basically required fields for Migration. The Image below\nshows the basic SYNC view where the fields with red dots are mandatory\nto fill.\n\nDomain Name\n~~~~~~~~~~~\n\nIt is a unique, representative name for a Remote which should help you\nto distinguish the Remote among the others easily. E.g: ``Lab_1``,\n``Barna_Lab`` and etc.\n\nSource URL\n~~~~~~~~~~\n\nURL of the Remote Instance to connect in order to query objects. It\nshould also contain the *portal* path of the remote instance. E.g:\n``https://192.168.1.5:8080/senaitelims``.\n\nUsername & Password\n~~~~~~~~~~~~~~~~~~~\n\nUser credentials to log in to the remote instance and start an HTTP\nsession.\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/required_fields.png\n :alt: Basic SYNC view.\n\n Basic SYNC view.\n\nOptional Configuration\n----------------------\n\nIf attention is paid to the image presented above it can be seen that\nthere is one field from the basic SYNC view that is not mandatory. This\nfield is *Certificate Path*.\n\nCertificate Path\n~~~~~~~~~~~~~~~~\n\nThis field should only be filled when synchronization is wanted to be\nmade over HTTPS and the instances that are to be synchronized reside in\na local network and are not accessible from the public internet. Why?\nBecause when using HTTPS to connect to another host the identity of this\nhost is validated via signed certificates. When the host is accessible\nfrom the public internet, these certificates are signed by authorized\nentities that are worldwide recognized. However, these authorized\nentities are not allowed to sign certificates for hosts that are not\naccessible from the public Internet.\n\nThe solution to this is to use self-signed certificates. This\ncertificates are signed by the same host that issues them and not by an\nauthorized entity. The problem that arises when using self-signed\ncertificates is that, since they aren\u2019t signed by an authorized entity,\nSYNC will not trust them by default.\n\nThis why this option exists, and it allows to explicitly tell SYNC to\ntrust a particular certificate.\n\nAdvanced Configuration\n----------------------\n\nThe following configuration options can be used for Synchronization and\nspecial cases. Make sure you understand all of them properly before you\nstart working with SYNC. The Image at the end of the section presents how\nthis set of advanced options looks in SENAITE.\n\nImport Configuration\n~~~~~~~~~~~~~~~~~~~~\n\nImport Settings\n^^^^^^^^^^^^^^^\n\nIf this option is enabled the Plone Configuration will be imported.\n\nImport Registry\n^^^^^^^^^^^^^^^\n\nIf this option is selected all the registry records containing the words\nbika or senaite will be imported. The registry is used by Plone to store\nsome of its configuration data in the form of records, in the most\ngeneral way.\n\nImport Users\n^^^^^^^^^^^^\n\nIf this option is enabled, then all Plone users from the Remote will be\ncreated on the destination instance keeping their roles in the Remote.\nRemember that you might need them to link with *Lab Contacts*.\n\nPrefixes Configuration\n~~~~~~~~~~~~~~~~~~~~~~\n\nRemote's Prefix\n^^^^^^^^^^^^^^^\n\nPrefixes are very important for Synchronization. When the user defines a\nPrefix for the Remote, it means, some objects will be created with that\nPrefix (see Prefixable Content Types) in the beginning of their ID's.\n\nLocal Prefix\n^^^^^^^^^^^^\n\nThis can be thought as the reverse way of Remote's Prefix. It must be\nfilled only in case that the current instance has been added as a remote\nin the source system with a prefix. And the prefix used for this\ninstance should be introduced here. It is obligatory for two-side\nSynchronization.\n\nContent Types Configuration\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nFull Sync Content Types\n^^^^^^^^^^^^^^^^^^^^^^^\n\nThis field is kind of a filter for the content types that the user wants\nto copy/full-synchronize. If it is empty, all content types will be\nretrieved from the source instance without any filter. But if it is\nfilled as *Client, Patient*, then only Clients and Patients will be\nimported in full-sync mood. Bear in mind that dependencies will be\nimported according to the configuration as well.\n\nContent Types to be Skipped\n^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIf filled, entered Content Types will be be imported unless they are\nrequired for other objects that are being imported. It can be useful\nwhen you want to upgrade your instance and you have some old\nCalculations which you don't use and you don't want to copy and deal\nwith.\n\nPrefixable Content Types\n^^^^^^^^^^^^^^^^^^^^^^^^\n\nThese are the objects which will contain *Remote's Prefix* in their IDs.\nMust be filled if Remote Prefix is not empty. Use case: Let's say you\nhave an Instance where you want to monitor Analyses from different labs.\nThen you can one remote for each of the labs on that instance, define\nprefixes and add Analyses and Analysis Requests to be imported with\nprefixes. In the end, you will have Analysis Requests and prefixes of\nthe lab they belong to in their ID's.\n\nRead-Only Content Types\n^^^^^^^^^^^^^^^^^^^^^^^\n\nAny content type defined in this field, will be imported to the\ndestination instance. However no one (including Lab Managers and\nAdministrators) will be able to make any change on these objects in the\ndestination instance.\n\nUpdate-Only Content Types\n^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThis field makes sense when two-side Sync is being used. It means, all\nthe objects that originally created on the current instance will be\nupdated according to the changes on the source instance. It takes into\naccount the *Local Prefix* and it is how the system knows which objects\nare from this current instance. For example, let's say we are\nconfiguring instance A and there is another instance B which has already\nimported Samples from instance A in prefixable mode (so all the samples\ncopied from A to B has a prefix ``A_``). When we add *Sample* to\n*Update-only Content Types*, all the Samples with prefix ``A_`` will get\nupdated according to B instance. However, other Samples which have been\ncreated on B itself will not be imported to A.\n\nAuto-Sync\n~~~~~~~~~\n\nYou can enable/disable auto Synchronization for each Remote from this\nfield. If not enabled, then updates can be obtained from SYNC view\nmanually.\n\nTo enable Auto-Sync, a part from selecting the required checkbox, a\n``clock server`` should be added to the instance. To do so, a new\n``.cfg`` file must be extended from the main ``buildout.cfg`` file of\nthe instance. The ``.cfg`` file must contain the following lines:\n\n::\n\n [instance]\n zope-conf-additional +=\n \n method //do_auto_sync\n period \n user \n password \n host \n \n\nAs an example:\n\n::\n\n [instance]\n zope-conf-additional +=\n \n method /Plone/do_auto_sync\n period 86400\n user labman\n password labman\n host localhost:8080\n \n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/advanced_options.png\n :alt: Advanced configuration options.\n\n Advanced configuration options.\n\nHow does it work?\n=================\n\nThe whole process can be examined in 3 steps; Fetch, Import and Update.\nLet\u2019s have a look at them.\n\nFetch\n-----\n\nFetching data happens right after when you are done with configuration\nand click *Fetch and Save* button. During this step, basic information\nabout will-be-imported objects (depending on your configuration), is\nobtained and saved in order to be used later steps. If you have a DB\nwith ~50 K objects, this step would take an hour approximately. Be\npatient and keen an eye on logs to see the progress, if you are\ninterested. Once Fetch is finished, you are ready to run the Import\nprocess.\n\nImport\n------\n\nImport Process is the step where objects will be created and updated\naccording to the Remote. Thus, it will always take much longer than\nFetch Step. To run the Import step, you can click on *Import* button of\ncorresponding Remote from SYNC View. For a DB with ~50 K objects, Import\nmight take up to 4-5 hours. Be patient and make sure you never have long\nHTTP/S connection problems.\n\nUpdate\n------\n\nUpdate Process is the last step of the SYNC which can be run any time to\nget changes and keep the destination up-to-date with the source\ninstance. This step doesn\u2019t take too long if you keep the interval\nshort. Bear in mind that if you have some objects that have been\nmodified in the source and destination instances independently from each\nother, this process will skip and not affect them.\n\nConfigure and Synchronize\n=========================\n\nIf you are confident enough that you understand how SYNC works and what\nyou need, then you can start to work with it. In this section we will\nprovide information and instructions on how to work with SYNC Add-on. We\nwill also provide some real examples. Let\u2019s get started!\n\nWe assume you have SYNC Add-on installed on your Senaite instance. In\nthis case, and if you have logged into the system as an Administrator or\na Manager, you must see SYNC after clicking on the menu icon located in\nthe top right corner. See the image below to visually locate the SYNC\nlink. Click on that and go to SYNC View. If this is your first time\nadding and you don\u2019t have any remote added previously, you will see only\nan empty page with *Add New Remote* button. Click and go to *Add New\nRemote* View. This is the page where we can configure the Remote and\nStart the Synchronization. In order to make it easy-to-understand, we\nwill give examples for each case we talked about in the first section.\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/link_to.png\n :alt: Where to find the link to SYNC.\n\n Where to find the link to SYNC.\n\nConfiguration for Migration\n---------------------------\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/ex_conf.png\n :alt: Example configuration for migration.\n\n Example configuration for migration.\n\nIf your aim is just to migrate and update your source instance as a new\none, you only need to fill required fields from the Add View. Since\nthere is no Advanced configuration, SYNC will just connect to the\nRemote, get all the data and Fetch it as it is in the Remote. The\nimage above presents an example of configuration for migration. If\nyou fill all the fields properly and click on *Save and Fetch* button,\ndata will be fetched and in the end you will see an informing message\nlike the one presented in the image below. It means you are ready to \nrun Import Step now. Click on *Show Remotes* button at the bottom of\nthe page and go to Remote Listing View. You will see that now there\nis some information regarding your Remote Configuration. The last \nimage of this section illustrates what each section of the *Remote Table*\nmeans with a real example.\n\nWe will give more information about other parts later but for now you\ncan Run import step by clicking on *Import* button. After a while,\nmigration will finish and you can enjoy your migrated instance on your\nnew Server!\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/fetch_finished.png\n :alt: Successfuly fetched test domain message.\n\n Successfuly fetched test domain message.\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/fetched_data.png\n :alt: Fetched data for the test domain.\n\n Fetched data for the test domain.\n\nBack-up Instance Configuration (One Way Sync)\n---------------------------------------------\n\nIn previous example we talked about the case when you want to migrate an\ninstance and then stop using that and start to work with the new,\nmigrated instance. However, it is possible that you have a very\nimportant instance with a very important DB, so to feel safer you want\nto have its back-up version. In order to do so, you obviously have to\nrun the migration for the first time.\n\nNow the important point here is about back-up period. It can be done\nperiodically by SYNC it self, or you can take the back-ups from time to\ntime by yourself. If you want to do copy Updates to your back-up\ninstance manually, you can do it from *Manual Update* section of the\nRemote\u2019s table. Just go to that page, run the import step manually by\nclicking on *Get Updates* button and that\u2019s it!\n\nIf you don\u2019t want to deal with Manual Updates, while configuring the\nRemote, you can enable *Auto Sync* option from *Advanced Configuration\nOptions* and SYNC will do it for you periodically. As you might guess,\nby this way it is also an example of *One Way Synchronization*.\n\nBidirectional Full Synchronization (BFS)\n----------------------------------------\n\nUntil now we have seen how to configure your destination instance to\nmigrate or synchronize unidirectionally. So basically, in your source\ninstance you didn\u2019t do anything with SYNC. But when it comes to\nBidirectional Sync, it is necessary to deal with SYNC on both instances.\nIn BFS case, your configuration will take place in two steps.\n\nLet\u2019s assume you have 2 instances; *Lab A* and *Lab B*. First you have\nto add *Lab B* as a Remote on *Lab A* instance. If you enable Auto-Sync,\nit means *Lab A* will always have changes of *Lab B*. So first step is\ndone! Now imagine you add *Lab A* as a Remote on *Lab B* with Auto-Sync\noption enabled. Now, all the changes from *Lab A* will be imported to\n*Lab B*. Considering that both labs will run SYNC periodically, they\nwill always be up-to-date with each other. Again remember that in the\ncase objects are modified on both instances at the same time period,\nchanges will be skipped.\n\nFull Sync for Multiple Instances\n--------------------------------\n\nBy applying the same logic we used for BFS, we can synchronize even more\nthan 2 instances. In that case, you just have to carefully decide which\ninstances must be Remote for which instances. It could also be done by\nadding all instances to each other, but it would just confuse you.\nInstead, you can apply the following logic:\n\nLet\u2019s say you have 4 instances (A, B, C, D) and you want all of them to\nbe Fully Synced. First choose an instance with the highest run-time and\nthink of it as the Master instance. Let\u2019s say A is the Master in our\ncase. Now, you have to add B, C and D as remotes to A and enable\nAuto-Sync. So, we are sure that A will always have the changes from rest\nof the instance. Now, go to B and add only A as a remote. What happens\nnow is, A will gather all the changes and since B will get the changes\nfrom A, B will have all the changes as well. Apply the last step to C\nand D instances and that\u2019s it!\n\nIf you have too many instances to be Synced, then you might want to have\nmore than one master. It would not cause any problem at all. Just make\nsure that you add all your remotes on them and on non-master (slave)\ninstances you add at least one of the Masters.\n\nAdvanced Sync\n-------------\n\nSo far we saw how to Migrate and do Full Sync which don\u2019t require\nAdvanced Configuration except for *Auto-Sync* option. Now we will try to\ngo deep to Advanced Configuration and see more complex examples. Before\nstarting with next examples please make sure that you understand what\neach of Advanced Configuration fields mean.\n\nExample 1\n~~~~~~~~~\n\nLet\u2019s think of the case where we have 5 Labs (A, B, C, D and M) and we\nwant to collaborate them in this way:\n\n- A, B, C and D are labs where samples and analyses are registered and\n sometimes reported.\n\n- A, B, C and D do the same work and share information with M and\n amongst each other for most of the objects (Department, Method and\n etc.), except for samples and analyses.\n\n- M is the central lab, where samples that have been registered on\n those labs are analyzed and reported.\n\n- If a Sample or an Analysis is updated on M, the information must be\n sent to the origin lab (and only to origin lab).\n\n- f there is an update in origin lab, M should get updated as well.\n\nIn this case M can be thought as the Master lab and A, B, C and D as\ncollaborators. It also means we will need 2 types of configuration: one\nfor M and one for the collaborators. Let\u2019s see what the configuration\nshould look like for M:\n\n- For each collaborator, a remote should be added on M.\n\n- Each Remote should have its unique Prefix .\n\n- Since Samples, Analyses and Analysis Requests are not shared data\n amongst collaborators, they must contain prefixes in order to be\n distinguishable.\n\n- Auto-Sync must be enabled.\n\nAnd configuration on collaborators:\n\n- Only one Remote- for the Master - should be added.\n\n- Local Prefix which indicates collaborator\u2019s prefix on Master must be\n introduced.\n\n- Since we do not want to import Samples, Analyses and Analysis\n Requests, they must be defined as *Update-only Types*.\n\nExample 2\n~~~~~~~~~\n\nLet\u2019s think of a more complex use of SYNC. For this example, assume all\nthe criteria from the previous one are given and there is one more\nrequirement:\n\n- Some objects such as Methods, Analysis Services and Calculations\n should be defined and handled only in the central instance. However,\n the collaborators must have access to them.\n\nIn this case, while configuring M, for all collaborator remotes we\nshould define these content types to be skipped. And in the collaborator\ninstances, we will define them inside *Read-only Content Types*. By this\nway, collaborators will be able to view and use them, but never to edit\nnor delete them. In the end, *Remote A* on Master instance must look as\nshown in the first image of the two presented below and Remote of Master\non collaborator instances as shown on the second one.\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/example_2.png\n :alt: Remote A configuration on the Master instance.\n\n Remote A configuration on the Master instance.\n\n.. figure:: https://raw.githubusercontent.com/senaite/senaite.sync/master/static/bis_example.png\n :alt: Remote Master instance configuration on collaborator instances.\n\n Remote Master instance configuration on collaborator instances.\n\n\n\nContribute\n==========\n\nWe want contributing to SENAITE.SYNC to be fun, enjoyable, and educational for\nanyone, and everyone. This project adheres to the `Contributor Covenant `_.\nBy participating, you are expected to uphold this code. Please report\nunacceptable behavior.\n\nContributions go far beyond pull requests and commits. Although we love giving\nyou the opportunity to put your stamp on SENAITE.SYNC, we also are thrilled to\nreceive a variety of other contributions. Please, read `Contributing to senaite.sync\ndocument `_.\n\n\nFeedback and support\n====================\n\n* `Gitter channel `_\n* `Users list `_\n\n\nLicense\n=======\n\nSENAITE.SYNC\nCopyright (C) 2018 Senaite Foundation\n\nThis program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.\n\nThis program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.\n\nSENAITE.SYNC uses third party libraries that are distributed under their own terms (see LICENSE-3RD-PARTY.rst)\n\n\nChangelog\n=========\n\n1.0.1 (unreleased)\n------------------\n\n**Added**\n\n\n**Changed**\n\n\n**Removed**\n\n\n**Fixed**\n\n- #62 Use full url for images in README so that they are shown on PyPi's project page\n\n**Security**\n\n\n\n1.0.0 (2018-07-16) \n------------------\n\n**Added**\n\n- #58 Include detailed installation instructions in the README\n- #58 Include functional documentation in the README\n- #56 Allow to specify the certificate to be used when connecting to the source instance\n- #46 Advanced Configuration: Local Prefix and Update only Content Types\n- #44 Advanced Configuration: 'Read-Only' Portal Types\n- #42 New Advanced Configuration Options\n- #34 Complement step for migration\n- #33 Recover step for failed objects in data import\n- #32 Log the estimated date of end\n- #32 Log the percentage of completion\n- #19 Configurable import\n- #16 Content type filtering\n- #14 Upgrade step machinery\n- #12 Settings import\n- #8 Periodic auto sync\n- #5 Import review history og objects\n- #4 Update object's workflow states\n- #3 Registry import\n\n**Changed**\n\n- #49 Make interface more user friendly\n- #53 Update API base url\n- #43 Querying last modified objects directly from 'uid_catalog'\n\n**Fixed**\n\n- #57 Handle errors in API resonse when fetching data\n- #50 Long term infinite loops in Update Step\n- #48 Auto Synchronization\n- #45 Error while Fetching Missing Parents\n- #39 Complement Step does not update all objects\n- #35 Bug- Complement Step yields all the items\n- #35 Complement Step yields all the items\n- #29 User creation when user email is empty\n- #28 Created users not being added to user groups\n- #27 Worksheet's analysis workflow state not being updated properly\n- #26 Clicking checkboxes' labels didn't affect their respective checkboxes\n- #25 Import error when folderish content type in source has been removed in destination\n- #24 Sync view wasn't properly rendered when not using `senaite.lims` add-on\n- #22 Creation flag wasn't being unset for objects under Bika Setup\n- #21 Attachments were not imported\n- #6 ProxyField setter fails when proxy object has not been set yet\n\n\n\n\nAuthors and maintainers\n-----------------------\n\n- Nihad Mammadli\n- Ramon Bartl (RIDING BYTES) \n- Juan Gallostra (naralabs) ", "description_content_type": "", "docs_url": null, "download_url": "", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/senaite/senaite.sync", "keywords": "", "license": "GPLv3", "maintainer": "", "maintainer_email": "", "name": "senaite.sync", "package_url": "https://pypi.org/project/senaite.sync/", "platform": "", "project_url": "https://pypi.org/project/senaite.sync/", "project_urls": { "Homepage": "https://github.com/senaite/senaite.sync" }, "release_url": "https://pypi.org/project/senaite.sync/1.0.1/", "requires_dist": null, "requires_python": "", "summary": "SENAITE SYNC", "version": "1.0.1" }, "last_serial": 5132794, "releases": { "1.0.0": [ { "comment_text": "", "digests": { "md5": "f4d49000600d55816879ededa6572faa", "sha256": "9d41c447ea5a3971cda956f010973ea0703dc7f8dfbe915e60ca0d7c762ec545" }, "downloads": -1, "filename": "senaite.sync-1.0.0.zip", "has_sig": false, "md5_digest": "f4d49000600d55816879ededa6572faa", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 79994, "upload_time": "2018-07-16T15:30:05", "url": "https://files.pythonhosted.org/packages/2f/5e/6c450bf1512b7de633184e59883244b91b5706414dfd4658d4638fd95dc2/senaite.sync-1.0.0.zip" } ], "1.0.1": [ { "comment_text": "", "digests": { "md5": "b67dd9a7db9350d5bb3c8886d1972b83", "sha256": "afc5899f6b72bf186d1feab6bd81434ce2782346b3b99e2780f7fdfdb232b2fc" }, "downloads": -1, "filename": "senaite.sync-1.0.1.zip", "has_sig": false, "md5_digest": "b67dd9a7db9350d5bb3c8886d1972b83", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 86888, "upload_time": "2019-04-12T07:55:27", "url": "https://files.pythonhosted.org/packages/08/bb/94ce6b625a3c6fe2d728a68e3558944bd500ddd8bd6c353378dd00a70cf7/senaite.sync-1.0.1.zip" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "b67dd9a7db9350d5bb3c8886d1972b83", "sha256": "afc5899f6b72bf186d1feab6bd81434ce2782346b3b99e2780f7fdfdb232b2fc" }, "downloads": -1, "filename": "senaite.sync-1.0.1.zip", "has_sig": false, "md5_digest": "b67dd9a7db9350d5bb3c8886d1972b83", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 86888, "upload_time": "2019-04-12T07:55:27", "url": "https://files.pythonhosted.org/packages/08/bb/94ce6b625a3c6fe2d728a68e3558944bd500ddd8bd6c353378dd00a70cf7/senaite.sync-1.0.1.zip" } ] }