Changes between Version 59 and Version 60 of ReleaseNotes
- Timestamp:
- 10.03.2013 00:31:30 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ReleaseNotes
v59 v60 16 16 * Encoded passwords are not visible in the webclient (#375). 17 17 * More complex searches for composite topics: you can e.g. search a person by its entire name. And you can search Persons or Institutions by combined Address terms (#420). 18 * Updating composite values perform faster (#339). 18 19 * More familiar wording of Core concepts: "Parent/Child" replaces "Whole/Part". This benefits both, API and GUI (#67). 19 20 * For developers: the Neo4j Shell can be launched while DeepaMehta is running [3601ae4a]. 20 21 21 Bug fixes:22 Access Control bug fixes: 22 23 * The admin user can change hers password (#369). 23 24 * A User Account is editable only by a) the respective user, and b) by the creator of the User Account (#375). 25 * The View Configurations of the standard types, e.g. Person, can be edited via GUI . They have access control information and Workspace assignments (#377). 26 * Association types get Workspace assignments (analogous to topic types) (#376). 27 28 Further bug fixes: 24 29 * View Configuration default values are reflected in the GUI. In particular the "Viewable", "Editable", and "Rows" settings are no longer changed by accident (#208). 25 * View Configurations of the standard types, e.g. Person, can be edited via GUI (#377). 26 * Association types get Workspace assignments (analogous to topic types) (#376). 30 * Multiple-value fields (cardinality "Many") can be involved in labeling rules (#250). 27 31 * Search topics and Webpage topics show no "Edit" button (#259, #248). 28 32 * After a multi-facet update topics do not appear twice in the webclient (#339). 33 * Deleting all Email Addresses or Phone Numbers from a Person or Institution does not throw an error (#414). 29 34 * A Person or an Institution can still be updated if Address child instances (Street, Postal Code, City, Country) are missing (#407). 30 35 31 36 Plugin Development Framework: 32 * The core class `CompositeValue` is attached to the DB. So, for complex update operations of composite topics/associations the developer must not care about model updates vs. DB-updates. The underlying model and the DB are always in-sync automatically. `CompositeValue` is now on-par with all the other Core objects (#339). 37 * The core class `CompositeValue` is attached to the DB. So, for complex update operations of composite values the plugin developer must not care about model updates vs. DB-updates. The underlying model and the DB are always in-sync automatically. `CompositeValue` is now on a par with all the other Core objects (#339). 38 * Composite values are loaded lazily (#411). 33 39 * The core classes `CompositeValue` and `CompositeValueModel` provide convenience accessors which take a "defaultValue" argument (#418). 34 40