Description of the issue/feature this PR addresses
Add the function 'is_relationship_object' to the JSON API since it is the only place where it is required. This function, as it name suggests, provides the functionality of checking if a brain or object is a relationship object.
It is useful when the JSON API works as a data provider for senaite.sync since this objects will automatically be created in the target instance and hence don't have to be fetched nor imported.
Technical note: The function that was defined in senaite.api is slightly different from the one impemented in this PR. The one from senaite.api looked like:
def is_relationship_object(brain_or_object):
"""Checks if the passed in brain or object is a relationship object
:param brain_or_object: A single catalog brain or content object
:return: True if the object is a relationship object
"""
parent = get_parent(brain_or_object)
if hasattr(parent, 'id') and parent.id == "at_references":
return True
return False
While the one in this PR is:
def is_relationship_object(brain_or_object):
"""Checks if the passed in brain or object is a relationship object
:param brain_or_object: A single catalog brain or content object
:return: True if the object is a relationship object
"""
if 'at_references' in get_path(brain_or_object):
return True
return False
This modification is due to:
I think it is safer and less prone to errors to perform the check using only the given brain or object, without relying on other objects.
The first implementation was raising an error (actually #13 solves this problem) when using it on some of the brains from uid_catalog. Since the portal path was not included in the brain's path for objects such as clients we weren't able to get its parent.
Current behavior before PR
The JSON API didn't provide the functionality of checking if an object was a relationship object. Instead, this functionality was living in senaite.api.
Desired behavior after PR is merged
The is_relationship_object check can be performed directly from the JSON API without having to call a function from senaite.api.
--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.
Coverage remained the same at ?% when pulling 07b5897c05db525ad26534b65ccb0f09bae5fe73 on juangallostra:is-relationship-object into 5e1e91debe2e784ebfd67e4c3dc65598e5e052b8 on senaite:master.
Description of the issue/feature this PR addresses
Add the function 'is_relationship_object' to the JSON API since it is the only place where it is required. This function, as it name suggests, provides the functionality of checking if a brain or object is a relationship object.
It is useful when the JSON API works as a data provider for
senaite.sync
since this objects will automatically be created in the target instance and hence don't have to be fetched nor imported.Technical note: The function that was defined in
senaite.api
is slightly different from the one impemented in this PR. The one fromsenaite.api
looked like:While the one in this PR is:
This modification is due to:
uid_catalog
. Since the portal path was not included in the brain's path for objects such asclients
we weren't able to get its parent.Current behavior before PR
The JSON API didn't provide the functionality of checking if an object was a relationship object. Instead, this functionality was living in
senaite.api
.Desired behavior after PR is merged
The
is_relationship_object
check can be performed directly from the JSON API without having to call a function fromsenaite.api
.-- I confirm I have tested this PR thoroughly and coded it according to PEP8 and Plone's Python styleguide standards.