targetprocess-py 0.2.0__tar.gz → 0.2.1__tar.gz

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/CHANGELOG.md

@@ -7,6 +7,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.1] - 2026-09-18
+
+### Fixed
+
+- A verified clear of a custom field (`update(..., verify=True)` or
+  `set_custom_field(id, name, None)`) no longer raises `VerificationError`
+  when the field reads back `False` or `0`. The re-read comparison now
+  accepts any of TargetProcess's empty-equivalent values - null, `""`,
+  `False` or `0` - as showing a requested clear, rather than only null or
+  `""`. This fixes clearing a `CheckBox` custom field, which reads back
+  `False`, and a numeric one, which reads back `0`; a *set* value of `False`
+  or `0` is unaffected and still compares exactly as before.
+
 ## [0.2.0] - 2026-09-17
 
 The first beta release.
@@ -162,6 +175,7 @@ The first public release.
 - Log scrubbing redacts the `access_token` query parameter and `Authorization`
   header values from the library's own log records.
 
-[Unreleased]: https://github.com/man8/targetprocess-py/compare/v0.2.0...HEAD
+[Unreleased]: https://github.com/man8/targetprocess-py/compare/v0.2.1...HEAD
+[0.2.1]: https://github.com/man8/targetprocess-py/compare/v0.2.0...v0.2.1
 [0.2.0]: https://github.com/man8/targetprocess-py/compare/v0.1.0...v0.2.0
 [0.1.0]: https://github.com/man8/targetprocess-py/releases/tag/v0.1.0

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: targetprocess-py
-Version: 0.2.0
+Version: 0.2.1
 Summary: A Python library for the TargetProcess v1 REST API
 Project-URL: Homepage, https://github.com/man8/targetprocess-py
 Project-URL: Repository, https://github.com/man8/targetprocess-py

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/SPEC.md

@@ -520,10 +520,11 @@ Every typed manager writes one with
 `{"CustomFields": [{"Name": name, "Value": value}]}` through `update`; a null
 `Value` clears. A partial update omitting a custom field keeps its value behind
 a success status, so `verify` defaults on here (off on `update`): the re-read
-matches the entry by name, a clear reading back null or `""`, and raises
-`VerificationError` when the value differs or no entry of that name comes back.
-A date-typed value reads back in wire form, so it verifies only when sent in
-that form (`format_tp_date`) or with `verify=False`.
+matches the entry by name, a clear reading back any of TP's empty-equivalent
+values - null, `""`, `False` or `0`, since a CheckBox reads back `False` and a
+numeric field `0` - and raises `VerificationError` when the value differs or no
+entry of that name comes back. A date-typed value reads back in wire form, so it
+verifies only when sent in that form (`format_tp_date`) or with `verify=False`.
 
 Nested references use one of four lightweight shapes, chosen by what the
 API actually sends:

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/docs/USAGE.md

@@ -245,7 +245,9 @@ story = await client.user_stories.set_custom_field(123, "Release note", None)
 Leaving a field out of an update is not a clear: TargetProcess keeps the old
 value and still answers with a success status. So `set_custom_field` verifies
 by default, re-reading `include=["CustomFields"]` and matching the entry by
-name (case-insensitively); a cleared field may read back as `None` or `""`.
+name (case-insensitively); a cleared field may read back as `None`, `""`,
+`False` or `0` - a CheckBox reads back `False`, and any of these empty
+equivalents counts, regardless of the field's own configured type.
 `VerificationError` here means the value did not land, a clear was discarded,
 or no field of that name exists on the entity's process - a misspelt name, or
 one configured on another process. Pass `verify=False` to skip the re-read.

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/src/targetprocess/__init__.py

@@ -112,7 +112,7 @@ from targetprocess.resources import (
 from targetprocess.response_parser import ResponseParser
 from targetprocess.types import ClientMode, LevelState, StateLevels, UpsertAction, UpsertResult
 
-__version__ = "0.2.0"
+__version__ = "0.2.1"
 
 __all__ = [
     # Exceptions

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/src/targetprocess/resources/_verify.py

@@ -7,12 +7,13 @@ matched against the raw re-read, by these rules in order:
 - A requested ``CustomFields`` sequence (any but a string, bytes or
   bytearray) is routed entry by entry before any other rule applies, each
   entry matched by name (case-insensitively). A cleared entry (``Value``
-  ``None``) matches an observed null or empty string, any other value is
-  compared by the rules below, and an entry of that name missing from the
-  re-read is a mismatch keyed ``CustomFields[<name>]``. An entry that is not
-  a mapping carrying a string ``Name`` cannot be looked up, so it is a
-  mismatch too, keyed by its zero-based position
-  (``CustomFields[#<position>]``) and observed as
+  ``None``) matches an observed null, ``""``, ``False`` or ``0`` - each is
+  TP's empty state for some field type, so accepting the set never masks a
+  failed clear. Any other value is compared by the rules below, and an entry
+  of that name missing from the re-read is a mismatch keyed
+  ``CustomFields[<name>]``. An entry that is not a mapping carrying a string
+  ``Name`` cannot be looked up, so it is a mismatch too, keyed by its
+  zero-based position (``CustomFields[#<position>]``) and observed as
   ``VerificationError.ABSENT``.
 - A requested key the re-read does not carry at all is a mismatch, observed
   as ``VerificationError.ABSENT`` - unless the request was ``None``, which an
@@ -122,7 +123,9 @@ def custom_field_mismatch(name: str, value: object, observed: object) -> Mismatc
 
     Args:
         name: The custom field's name, matched case-insensitively.
-        value: The value the write sent; ``None`` is a clear.
+        value: The value the write sent; ``None`` is a clear, verified by an
+            observed null, ``""``, ``False`` or ``0`` - any of TP's empty
+            states, regardless of the field's own ``Type``.
         observed: The re-read's ``CustomFields`` list (or whatever it carried).
 
     Returns:
@@ -137,7 +140,11 @@ def custom_field_mismatch(name: str, value: object, observed: object) -> Mismatc
         _, entry_name = _get(entry, "Name")
         if isinstance(entry_name, str) and entry_name.strip().casefold() == wanted:
             _, seen = _get(entry, "Value")
-            cleared = value is None and (seen is None or seen == "")
+            # Each of null, "", False and 0 is TP's empty state for some field
+            # type, so accepting the set on a requested clear cannot mask a
+            # failed one: for it to pass wrongly the field would already have
+            # to be holding an empty value.
+            cleared = value is None and seen in (None, "", False, 0)
             return None if cleared or values_match(value, seen) else (value, seen)
     return (value, ABSENT)
 

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/src/targetprocess/resources/base.py

@@ -889,8 +889,10 @@ class BaseResource[T: Entity]:
         discarded custom-field write is otherwise silent. The re-read requests
         ``include=[CustomFields]``, finds the entry whose name matches
         ``name`` case-insensitively, and compares its value; a cleared field
-        reads back as null or an empty string, and either counts. A name that
-        is misspelt, or belongs to another process's configuration, reads
+        reads back as null, an empty string, ``False`` or ``0`` - TP's empty
+        state for some field type (a CheckBox reads back ``False``) - and any
+        of them counts, regardless of the field's own configured type. A name
+        that is misspelt, or belongs to another process's configuration, reads
         back no entry at all and raises too. Values are compared as sent, with
         no conversion between forms: a date-typed field reads back as a
         ``/Date(ms±HHMM)/`` wire string, so it verifies only when the value

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/tests/test_resources/test_custom_field_writes.py

@@ -64,9 +64,15 @@ async def test_clear_sends_a_null_value() -> None:
     assert json.loads(log[0].content) == {"CustomFields": [{"Name": "Deadline", "Value": None}]}
 
 
-@pytest.mark.parametrize("cleared", [None, ""])
-async def test_clear_verifies_against_null_or_empty(cleared: str | None) -> None:
-    client, log = _client(_with_fields({"Name": "Deadline", "Type": "Text", "Value": cleared}))
+@pytest.mark.parametrize(
+    ("cleared", "field_type"),
+    [(None, "Text"), ("", "Text"), (False, "CheckBox"), (0, "Number")],
+    ids=["null", "empty-string", "checkbox-false", "numeric-zero"],
+)
+async def test_clear_verifies_against_any_empty_equivalent(
+    cleared: str | bool | int | None, field_type: str
+) -> None:
+    client, log = _client(_with_fields({"Name": "Deadline", "Type": field_type, "Value": cleared}))
 
     story = await client.user_stories.set_custom_field(123, "Deadline", None)
 

{targetprocess_py-0.2.0 → targetprocess_py-0.2.1}/tests/test_resources/test_verified_writes.py

@@ -569,6 +569,36 @@ def test_custom_field_mismatch_accepts_null_or_empty_as_cleared() -> None:
     assert custom_field_mismatch("Ticket", None, [{"Name": "Ticket", "Value": "x"}]) == (None, "x")
 
 
+@pytest.mark.parametrize(
+    "observed",
+    [None, "", False, 0],
+    ids=["null", "empty-string", "checkbox-false", "numeric-zero"],
+)
+def test_custom_field_mismatch_accepts_any_empty_equivalent_as_cleared(observed: object) -> None:
+    assert custom_field_mismatch("Done", None, [{"Name": "Done", "Value": observed}]) is None
+
+
+@pytest.mark.parametrize(
+    "observed",
+    [True, 3, "x"],
+    ids=["checkbox-true", "non-zero-number", "populated-string"],
+)
+def test_custom_field_mismatch_still_raises_a_clear_against_a_non_empty_value(
+    observed: object,
+) -> None:
+    assert custom_field_mismatch("Done", None, [{"Name": "Done", "Value": observed}]) == (
+        None,
+        observed,
+    )
+
+
+def test_custom_field_mismatch_does_not_treat_a_requested_false_as_clearing_against_zero() -> None:
+    # R2: the empty-equivalent widening applies only when the *requested* value
+    # is None - a requested False is a set value and still compares through
+    # values_match, which treats bool and int as different types.
+    assert custom_field_mismatch("Done", False, [{"Name": "Done", "Value": 0}]) == (False, 0)
+
+
 def test_custom_field_mismatch_reports_an_absent_entry() -> None:
     assert custom_field_mismatch("Ticket", "x", []) == ("x", _ABSENT)
     assert custom_field_mismatch("Ticket", "x", None) == ("x", _ABSENT)