easyvista-python-client 0.4.3__tar.gz → 0.5.0__tar.gz

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/CHANGELOG.md

@@ -15,6 +15,46 @@ is the error. Tags carry no `v` prefix.
 
 ## [Unreleased]
 
+## [0.5.0] - 2026-11-10
+
+Two more of the vendor's ticket requests, and a guard that names one more
+column. Neither new method takes a status: the package still has no status
+setter.
+
+### Added
+
+- **`suspend_ticket(rfc_number, *, allow_workflow_effect, comment=None,
+  done_by_id=None)`** and **`restart_ticket(...)`** (same signature), the
+  vendor's suspend and restart requests
+  ([suspend](https://docs.easyvista.com/docs/rest-api-suspend-an-incident-request.md),
+  [restart](https://docs.easyvista.com/docs/rest-api-reopen-an-incident-request.md)):
+  `PUT requests/{rfc_number}` with a `suspended` / `restarted` object. The guard
+  already named both bodies `WorkflowEffect.UNKNOWN`, so
+  `allow_workflow_effect` is a required keyword and the call is refused before
+  any request unless it includes `UNKNOWN`; an allowed request is sent once,
+  never retried. `comment` and `done_by_id` are left out of the body when
+  `None`. The return value is parsed as `close_ticket`'s is.
+
+### Changed
+
+- **BREAKING:** the workflow guard now names `STATUS_ID_ON_CREATE` on an
+  existing action (`update_action`, or `PUT actions/{id}` through `send`), as
+  it does `STATUS_ID_ON_TERMINATE`. A write that passed before is refused
+  without `allow_workflow_effect=WorkflowEffect.UNKNOWN`. Measured 2026-11-09
+  and 2026-11-10 on one instance (tier 4, may not generalise): a write to it
+  on an existing action changed where the ticket's status went. Creating an
+  action or a task is unchanged: the server overwrites the column on create.
+
+### Fixed
+
+- **The `reassign_action` documentation about `OWNING_GROUP_ID`.** It said the
+  ticket's owning group does not follow a reassigned step. Measured 2026-11-04
+  to 2026-11-10 on one instance (several tickets, may not generalise): it
+  follows after a few seconds to about two minutes (consistent with a
+  server-side job; inferred, not observed), and `LAST_UPDATE` moves with it;
+  the first reading was taken too soon. The status still does not move, the
+  step is not started and no action row is added.
+
 ## [0.4.3] - 2026-10-08
 
 A patch release of the content reader: a caller can recognise the images a
@@ -1690,7 +1730,8 @@ Initial public release.
   status/error code, with non-retryable validation errors (HTTP 590, code 2013).
 - `py.typed` marker — the package ships inline type information.
 
-[Unreleased]: https://github.com/baraline/easyvista_python_client/compare/0.4.3...HEAD
+[Unreleased]: https://github.com/baraline/easyvista_python_client/compare/0.5.0...HEAD
+[0.5.0]: https://github.com/baraline/easyvista_python_client/compare/0.4.3...0.5.0
 [0.4.3]: https://github.com/baraline/easyvista_python_client/compare/0.4.2...0.4.3
 [0.4.2]: https://github.com/baraline/easyvista_python_client/compare/0.4.1...0.4.2
 [0.4.1]: https://github.com/baraline/easyvista_python_client/compare/0.4.0...0.4.1

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: easyvista-python-client
-Version: 0.4.3
+Version: 0.5.0
 Summary: Typed Python client for the EasyVista Service Manager REST API
 Project-URL: Homepage, https://github.com/baraline/easyvista_python_client
 Project-URL: Documentation, https://easyvista-python-client.readthedocs.io/en/latest/

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/docs/user_guide.rst

@@ -473,8 +473,9 @@ rule on your instance can run on any write.
 To escalate the open workflow step to another group without ending it, use
 :meth:`~easyvista_python_client.EasyvistaClient.reassign_action` (measured
 2026-10-02, one instance, so it may not generalise: the step stays open and the
-status does not move; the ticket's owning group, read on one ticket, did not
-follow).
+status does not move; measured 2026-11-04 to 2026-11-10, several tickets, the
+ticket's owning group follows the step's new group after a few seconds to about
+two minutes).
 
 Creating a ticket starts its workflow -- the vendor's create page lists "The
 workflow associated with the ticket is started." among what a create does (tier

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/docs/vendor-api-reference.md

@@ -287,10 +287,16 @@ again five seconds later); the step **stayed open** (`END_DATE_UT` empty); the t
 status and `END_DATE_UT` **did not move**; the open actions were unchanged; and **no new
 action rows** appeared. On the **first ticket only** the step was recorded as a type-20
 action with `WORKFLOW_ID` set, its `WORKFLOW_ID` was unchanged, `DONE_BY_ID` stayed
-empty and no ticket field changed; and that is also the only ticket on which the
-ticket's own `OWNING_GROUP_ID` was read — it **stayed at the old group**, so the
-ticket's owning group did not follow the action's. Reassigning to a person
-(`done_by_id`) was **not measured**. Whether the UI wizard's notifications fire is not
+empty and no ticket field changed. The ticket's own `OWNING_GROUP_ID` was read on
+that ticket only, and had not moved; that reading was taken too soon. Measured
+2026-11-04 to 2026-11-10 on one instance (several tickets, may not generalise): the
+ticket's `OWNING_GROUP_ID` **follows the step's new group** after a delay of a few
+seconds to about two minutes (consistent with a server-side job; inferred, not
+observed), and `LAST_UPDATE` moves with it; the status still does not move, the step
+is not started and no action row is added. Also measured 2026-11-04 on one ticket:
+after `done_by_id` was written on the step, the ticket's `OWNER_ID` followed about
+1 min 45 s later. The person's effect on the step was not measured beyond that one
+`OWNER_ID` observation. Whether the UI wizard's notifications fire is not
 observable from the API.
 
 **Business rules can fire on any write** — "On Insert/On Update" of any record

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/easyvista_python_client/_async/client.py

@@ -610,6 +610,99 @@ class AsyncEasyvistaClient:
         )
         return parse(await self._transport.send(spec.allowing(allow_workflow_effect)))
 
+    async def suspend_ticket(
+        self,
+        rfc_number: str,
+        *,
+        allow_workflow_effect: WorkflowEffect | Iterable[WorkflowEffect],
+        comment: str | None = None,
+        done_by_id: int | None = None,
+    ) -> Request:
+        """Suspend a ticket -- the vendor's suspend request.
+
+        Sends ``PUT requests/{rfc}`` with a ``suspended`` body, as the vendor
+        documents it:
+        https://docs.easyvista.com/docs/rest-api-suspend-an-incident-request.md
+        (tier 1, re-read 2026-11-10). The page documents two optional
+        parameters, ``comment`` and ``done_by_id`` (an employee id), and no
+        target status. Both are left out of the body when ``None``. A ticket
+        that is already suspended is refused by the server (400, "The request
+        is already suspended. Operation aborted.").
+
+        Measured 2026-11-04 to 2026-11-10 on one instance (tier 4, may not
+        generalise): the ticket moved to the instance's suspended status and
+        one already-ended suspension action carrying the comment was added;
+        the workflow step stayed open. A status key sent in the body was
+        ignored (measured 2026-11-04). The request takes no status, and the
+        package has no status setter.
+
+        ``allow_workflow_effect`` is **required**: nothing documents what a
+        suspend does to the workflow, so the write is named
+        ``WorkflowEffect.UNKNOWN`` and refused with
+        :class:`~easyvista_python_client.EasyvistaWorkflowEffectRefused`
+        before any request is made unless the call allows it. The allowed
+        request is sent once, never retried. The return value is parsed like
+        :meth:`close_ticket`'s: the vendor answers 201 with an ``HREF`` only, so
+        re-read with :meth:`get_ticket` to see the status::
+
+            client.suspend_ticket(
+                rfc,
+                allow_workflow_effect=WorkflowEffect.UNKNOWN,
+                comment="Waiting for the requester",
+            )
+        """
+        spec, parse = requests_res.build_suspend_ticket(
+            rfc_number,
+            comment=comment,
+            done_by_id=done_by_id,
+            context=self._validation_context,
+        )
+        return parse(await self._transport.send(spec.allowing(allow_workflow_effect)))
+
+    async def restart_ticket(
+        self,
+        rfc_number: str,
+        *,
+        allow_workflow_effect: WorkflowEffect | Iterable[WorkflowEffect],
+        comment: str | None = None,
+        done_by_id: int | None = None,
+    ) -> Request:
+        """Restart a suspended ticket -- the vendor's restart request.
+
+        Sends ``PUT requests/{rfc}`` with a ``restarted`` body, as the vendor
+        documents it:
+        https://docs.easyvista.com/docs/rest-api-reopen-an-incident-request.md
+        (tier 1, re-read 2026-11-10). The page documents two optional
+        parameters, ``comment`` and ``done_by_id`` (an employee id), and no
+        target status; its example marks ``comment`` as required while its
+        table lists it as optional, so this method leaves it out of the body
+        when ``None``. On a ticket that is not suspended the server answers
+        400 with "The request is not suspended. Operation aborted.".
+
+        Measured 2026-11-04 to 2026-11-10 on one instance (tier 4, may not
+        generalise): the request added one end-of-suspension action and, in
+        the tested case, returned the ticket to the status it was suspended
+        from; a restart on a ticket that was not suspended was refused with
+        the documented message, as HTTP 590 rather than the documented 400.
+        A status key sent in the body was ignored
+        (measured 2026-11-04). The request takes no status, and the package
+        has no status setter.
+
+        ``allow_workflow_effect`` is **required** and is
+        ``WorkflowEffect.UNKNOWN``, as for :meth:`suspend_ticket`: refused
+        before any request unless allowed, and sent once, never retried. The
+        return value is parsed like :meth:`close_ticket`'s (an ``HREF`` only)::
+
+            client.restart_ticket(rfc, allow_workflow_effect=WorkflowEffect.UNKNOWN)
+        """
+        spec, parse = requests_res.build_restart_ticket(
+            rfc_number,
+            comment=comment,
+            done_by_id=done_by_id,
+            context=self._validation_context,
+        )
+        return parse(await self._transport.send(spec.allowing(allow_workflow_effect)))
+
     # --- actions -------------------------------------------------------------
     async def create_action(
         self,
@@ -947,14 +1040,20 @@ class AsyncEasyvistaClient:
         the **first ticket only** the step was recorded as a type-20 action
         with ``WORKFLOW_ID`` set; its ``WORKFLOW_ID`` was unchanged,
         ``DONE_BY_ID`` stayed empty, and no ticket field changed.
-        **The ticket's own ``OWNING_GROUP_ID`` does not follow the action's
-        group** -- it stayed 57 on the first ticket, the only one read for it,
-        so reassigning a step is not reassigning the ticket. The lower-case
-        key ``group_id`` was the one sent; the upper-case spelling was never
-        needed. The person (``done_by_id``) was **not measured**: the same
-        body shape is sent, but nothing here shows what the instance does
-        with it. Whether the UI wizard's notifications fire is not observable
-        from the API.
+        The ticket's own ``OWNING_GROUP_ID`` was read at the time on one
+        ticket only and had not moved; that reading was taken too soon.
+        Measured 2026-11-04 to 2026-11-10 on one instance (several tickets,
+        may not generalise): the ticket's ``OWNING_GROUP_ID`` follows the
+        step's new group after a delay of a few seconds to about two minutes,
+        consistent with a server-side job (inferred, not observed), and
+        ``LAST_UPDATE`` moves with it. What still holds: the status does not
+        move, the step is not started and no action row is added. Also
+        measured 2026-11-04 on one ticket: after ``done_by_id`` was written on
+        the step, the ticket's ``OWNER_ID`` followed about 1 min 45 s later.
+        The lower-case key ``group_id`` was the one sent; the upper-case
+        spelling was never needed. The person's effect on the step was not
+        measured beyond that one ``OWNER_ID`` observation. Whether the UI
+        wizard's notifications fire is not observable from the API.
 
         Not refused by the workflow guard: the group and the person are data
         the workflow reads, not workflow state. Re-read with :meth:`get_action`

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/easyvista_python_client/_sync/client.py

@@ -610,6 +610,99 @@ class EasyvistaClient:
         )
         return parse(self._transport.send(spec.allowing(allow_workflow_effect)))
 
+    def suspend_ticket(
+        self,
+        rfc_number: str,
+        *,
+        allow_workflow_effect: WorkflowEffect | Iterable[WorkflowEffect],
+        comment: str | None = None,
+        done_by_id: int | None = None,
+    ) -> Request:
+        """Suspend a ticket -- the vendor's suspend request.
+
+        Sends ``PUT requests/{rfc}`` with a ``suspended`` body, as the vendor
+        documents it:
+        https://docs.easyvista.com/docs/rest-api-suspend-an-incident-request.md
+        (tier 1, re-read 2026-11-10). The page documents two optional
+        parameters, ``comment`` and ``done_by_id`` (an employee id), and no
+        target status. Both are left out of the body when ``None``. A ticket
+        that is already suspended is refused by the server (400, "The request
+        is already suspended. Operation aborted.").
+
+        Measured 2026-11-04 to 2026-11-10 on one instance (tier 4, may not
+        generalise): the ticket moved to the instance's suspended status and
+        one already-ended suspension action carrying the comment was added;
+        the workflow step stayed open. A status key sent in the body was
+        ignored (measured 2026-11-04). The request takes no status, and the
+        package has no status setter.
+
+        ``allow_workflow_effect`` is **required**: nothing documents what a
+        suspend does to the workflow, so the write is named
+        ``WorkflowEffect.UNKNOWN`` and refused with
+        :class:`~easyvista_python_client.EasyvistaWorkflowEffectRefused`
+        before any request is made unless the call allows it. The allowed
+        request is sent once, never retried. The return value is parsed like
+        :meth:`close_ticket`'s: the vendor answers 201 with an ``HREF`` only, so
+        re-read with :meth:`get_ticket` to see the status::
+
+            client.suspend_ticket(
+                rfc,
+                allow_workflow_effect=WorkflowEffect.UNKNOWN,
+                comment="Waiting for the requester",
+            )
+        """
+        spec, parse = requests_res.build_suspend_ticket(
+            rfc_number,
+            comment=comment,
+            done_by_id=done_by_id,
+            context=self._validation_context,
+        )
+        return parse(self._transport.send(spec.allowing(allow_workflow_effect)))
+
+    def restart_ticket(
+        self,
+        rfc_number: str,
+        *,
+        allow_workflow_effect: WorkflowEffect | Iterable[WorkflowEffect],
+        comment: str | None = None,
+        done_by_id: int | None = None,
+    ) -> Request:
+        """Restart a suspended ticket -- the vendor's restart request.
+
+        Sends ``PUT requests/{rfc}`` with a ``restarted`` body, as the vendor
+        documents it:
+        https://docs.easyvista.com/docs/rest-api-reopen-an-incident-request.md
+        (tier 1, re-read 2026-11-10). The page documents two optional
+        parameters, ``comment`` and ``done_by_id`` (an employee id), and no
+        target status; its example marks ``comment`` as required while its
+        table lists it as optional, so this method leaves it out of the body
+        when ``None``. On a ticket that is not suspended the server answers
+        400 with "The request is not suspended. Operation aborted.".
+
+        Measured 2026-11-04 to 2026-11-10 on one instance (tier 4, may not
+        generalise): the request added one end-of-suspension action and, in
+        the tested case, returned the ticket to the status it was suspended
+        from; a restart on a ticket that was not suspended was refused with
+        the documented message, as HTTP 590 rather than the documented 400.
+        A status key sent in the body was ignored
+        (measured 2026-11-04). The request takes no status, and the package
+        has no status setter.
+
+        ``allow_workflow_effect`` is **required** and is
+        ``WorkflowEffect.UNKNOWN``, as for :meth:`suspend_ticket`: refused
+        before any request unless allowed, and sent once, never retried. The
+        return value is parsed like :meth:`close_ticket`'s (an ``HREF`` only)::
+
+            client.restart_ticket(rfc, allow_workflow_effect=WorkflowEffect.UNKNOWN)
+        """
+        spec, parse = requests_res.build_restart_ticket(
+            rfc_number,
+            comment=comment,
+            done_by_id=done_by_id,
+            context=self._validation_context,
+        )
+        return parse(self._transport.send(spec.allowing(allow_workflow_effect)))
+
     # --- actions -------------------------------------------------------------
     def create_action(
         self,
@@ -947,14 +1040,20 @@ class EasyvistaClient:
         the **first ticket only** the step was recorded as a type-20 action
         with ``WORKFLOW_ID`` set; its ``WORKFLOW_ID`` was unchanged,
         ``DONE_BY_ID`` stayed empty, and no ticket field changed.
-        **The ticket's own ``OWNING_GROUP_ID`` does not follow the action's
-        group** -- it stayed 57 on the first ticket, the only one read for it,
-        so reassigning a step is not reassigning the ticket. The lower-case
-        key ``group_id`` was the one sent; the upper-case spelling was never
-        needed. The person (``done_by_id``) was **not measured**: the same
-        body shape is sent, but nothing here shows what the instance does
-        with it. Whether the UI wizard's notifications fire is not observable
-        from the API.
+        The ticket's own ``OWNING_GROUP_ID`` was read at the time on one
+        ticket only and had not moved; that reading was taken too soon.
+        Measured 2026-11-04 to 2026-11-10 on one instance (several tickets,
+        may not generalise): the ticket's ``OWNING_GROUP_ID`` follows the
+        step's new group after a delay of a few seconds to about two minutes,
+        consistent with a server-side job (inferred, not observed), and
+        ``LAST_UPDATE`` moves with it. What still holds: the status does not
+        move, the step is not started and no action row is added. Also
+        measured 2026-11-04 on one ticket: after ``done_by_id`` was written on
+        the step, the ticket's ``OWNER_ID`` followed about 1 min 45 s later.
+        The lower-case key ``group_id`` was the one sent; the upper-case
+        spelling was never needed. The person's effect on the step was not
+        measured beyond that one ``OWNER_ID`` observation. Whether the UI
+        wizard's notifications fire is not observable from the API.
 
         Not refused by the workflow guard: the group and the person are data
         the workflow reads, not workflow state. Re-read with :meth:`get_action`

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/easyvista_python_client/_version.py

@@ -5,4 +5,4 @@
 live only in ``__init__``.
 """
 
-__version__ = "0.4.3"
+__version__ = "0.5.0"

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/easyvista_python_client/resources/requests.py

@@ -140,3 +140,71 @@ def build_close_ticket(
         )
 
     return spec, parse
+
+
+def _build_state_request(
+    wrapper: str,
+    rfc_number: str,
+    *,
+    comment: str | None,
+    done_by_id: int | None,
+    context: dict[str, Any] | None,
+) -> tuple[RequestSpec, Callable[[Any], Request]]:
+    body: dict[str, Any] = {}
+    if comment is not None:
+        body["comment"] = comment
+    if done_by_id is not None:
+        body["done_by_id"] = done_by_id
+    spec = RequestSpec("PUT", f"requests/{rfc_number}", json={wrapper: body})
+
+    def parse(data: Any) -> Request:
+        records = extract_records(data, REQUESTS.envelope_key)
+        return Request.model_validate(
+            records[0] if records else data, context=context
+        )
+
+    return spec, parse
+
+
+def build_suspend_ticket(
+    rfc_number: str,
+    *,
+    comment: str | None = None,
+    done_by_id: int | None = None,
+    context: dict[str, Any] | None = None,
+) -> tuple[RequestSpec, Callable[[Any], Request]]:
+    """Build the ``{"suspended": {...}}`` PUT spec -- the vendor's suspend request.
+
+    https://docs.easyvista.com/docs/rest-api-suspend-an-incident-request.md
+    (tier 1): ``comment`` and ``done_by_id`` are the page's two optional
+    parameters, and both are left out of the body when ``None``.
+    """
+    return _build_state_request(
+        "suspended",
+        rfc_number,
+        comment=comment,
+        done_by_id=done_by_id,
+        context=context,
+    )
+
+
+def build_restart_ticket(
+    rfc_number: str,
+    *,
+    comment: str | None = None,
+    done_by_id: int | None = None,
+    context: dict[str, Any] | None = None,
+) -> tuple[RequestSpec, Callable[[Any], Request]]:
+    """Build the ``{"restarted": {...}}`` PUT spec -- the vendor's restart request.
+
+    https://docs.easyvista.com/docs/rest-api-reopen-an-incident-request.md
+    (tier 1): ``comment`` and ``done_by_id`` are the page's two optional
+    parameters, and both are left out of the body when ``None``.
+    """
+    return _build_state_request(
+        "restarted",
+        rfc_number,
+        comment=comment,
+        done_by_id=done_by_id,
+        context=context,
+    )

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/easyvista_python_client/workflow.py

@@ -35,7 +35,8 @@ site allowed it explicitly, with ``allow_workflow_effect=``.
 ``end_action``, ``suspended``, ``restarted`` -- as a top-level body key, in any
 casing, on any path. (2) On ticket and action routes, the columns that hold or
 select workflow state: a status, a catalog (which selects the workflow), the
-workflow, stage and step links, and on an existing action its end date, type,
+workflow, stage and step links, and on an existing action its end date, the
+statuses it sets (``status_id_on_terminate``, ``status_id_on_create``), type,
 parent or ticket (creating an action or a task names a narrower set, below).
 (3) Ticket sub-routes that are workflow commands rather than records, and
 ``requests/without-workflow`` and the deletion of a ticket. (4) A write to
@@ -114,11 +115,17 @@ _REQUEST_COLUMNS = frozenset(
 )
 
 #: Columns on ``actions/{id}`` that end, re-type, re-parent or move an action.
+#: ``status_id_on_create``: workflow state. Measured 2026-11-09 and 2026-11-10
+#: on one instance (tier 4, may not generalise): a write to it on an existing
+#: action changed where the ticket's status went. Not in the create sets
+#: below: on create the server overwrites it with the current status
+#: (measured 2026-11-05).
 _ACTION_COLUMNS = frozenset(
     {
         "end_date_ut",
         "end_date",
         "status_id_on_terminate",
+        "status_id_on_create",
         "workflow_id",
         "stage_id",
         "process_step_id",

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/pyproject.toml

@@ -44,7 +44,7 @@ exclude = [
 
 [project]
 name = "easyvista-python-client"
-version = "0.4.3"
+version = "0.5.0"
 description = "Typed Python client for the EasyVista Service Manager REST API"
 readme = "README.md"
 requires-python = ">=3.11"

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-asset-workflow/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and a profile authorized for the assets resource."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-client-setup/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and valid EasyVista credentials."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 `easyvista_python_client` ships both clients over one surface:

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-directory/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and a profile authorized for the departments and employees resources (writes are additionally profile-gated)."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-document-workflow/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and a profile authorized for the documents sub-resource."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-instance-discovery/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, and network access to an EasyVista Service Manager REST API. Every call here is a GET; nothing is created, updated or deleted."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-reporting-and-context/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, and network access to an EasyVista Service Manager REST API."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-search-syntax/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, and network access to an EasyVista Service Manager REST API."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-ticket-actions/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and a profile authorized for the actions sub-resource."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,
@@ -388,11 +388,17 @@ UI's transfer is a wizard), so the effect is measured, not specified. Measured
 2026-10-02 on one instance (Service Manager 2025.3; two tickets, so it may not
 generalise): the group was stored (`GROUP_ID` 57 to 50 on the open workflow step
 of both tickets); the step stayed open and the ticket's status did not move; the
-open actions were unchanged and no new action rows appeared. **The ticket's own
-`OWNING_GROUP_ID` does not follow the action's group** (it stayed 57 on the first
-ticket, the only one read for it), so reassigning a step is not reassigning the
-ticket. Reassigning to a person (`done_by_id`) was **not measured**, and whether
-the UI wizard's notifications fire is not observable from the API.
+open actions were unchanged and no new action rows appeared. The ticket's own
+`OWNING_GROUP_ID` was read on one ticket only and had not moved; that reading was
+taken too soon. Measured 2026-11-04 to 2026-11-10 on one instance (several tickets,
+may not generalise): **the ticket's `OWNING_GROUP_ID` follows the step's new group**
+after a delay of a few seconds to about two minutes (consistent with a server-side
+job; inferred, not observed; `LAST_UPDATE` moves with it); the status does not move,
+the step is not started and no action row is added. Also measured 2026-11-04 on one
+ticket: after `done_by_id` was written on the step, the ticket's `OWNER_ID` followed
+about 1 min 45 s later. The person's effect on the step was not measured beyond that
+one `OWNER_ID` observation, and whether the UI wizard's notifications fire is not
+observable from the API.
 `reassign_action` is not refused by the workflow guard, because the group and the
 person are data the workflow reads, not workflow state.
 

{easyvista_python_client-0.4.3 → easyvista_python_client-0.5.0}/skills/easyvista-ticket-workflow/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: "Requires Python 3.11+, easyvista-python-client, network access to an EasyVista Service Manager REST API, and a profile authorized for the requests resource."
 metadata:
   package: easyvista-python-client
-  version: "0.4.3"
+  version: "0.5.0"
 ---
 
 > **Sync and async.** Examples use `EasyvistaClient`. For `AsyncEasyvistaClient`,
@@ -199,6 +199,40 @@ a `TypeError`), and a value that does not include `WorkflowEffect.INTERRUPTS` is
 refused before any request is sent (see the first Gotcha). `WorkflowEffect` and
 `EasyvistaWorkflowEffectRefused` are both importable from the package root.
 
+### Suspend and restart
+
+`suspend_ticket` and `restart_ticket` are the vendor's suspend and restart requests
+(tier 1: `rest-api-suspend-an-incident-request.md`,
+`rest-api-reopen-an-incident-request.md`). Each takes an optional `comment` and an
+optional `done_by_id`, and no status. They are not status setters. Both require
+`allow_workflow_effect` and are refused before any request unless it includes
+`WorkflowEffect.UNKNOWN`; an allowed request is sent once, never retried.
+
+```python
+from easyvista_python_client import EasyvistaClient, WorkflowEffect
+
+with EasyvistaClient.from_env() as client:
+    client.suspend_ticket(
+        "YOUR_RFC_NUMBER",
+        allow_workflow_effect=WorkflowEffect.UNKNOWN,
+        comment="Waiting for the requester",
+    )
+    client.restart_ticket(
+        "YOUR_RFC_NUMBER",
+        allow_workflow_effect=WorkflowEffect.UNKNOWN,
+        comment="Requester answered",
+    )
+    # Re-read: the answer carries an HREF only.
+    print(client.get_ticket("YOUR_RFC_NUMBER").status_id)
+```
+
+Measured 2026-11-04 to 2026-11-10 on one instance (tier 4, may not generalise): a
+suspend moves the ticket to the instance's suspended status and adds one
+already-ended suspension action carrying the comment, with the workflow step left
+open; a restart adds one end-of-suspension action and, in the tested case, returns
+the ticket to the status it was suspended from; a restart on a ticket that is not suspended is refused with "The request is
+not suspended. Operation aborted."
+
 ```python
 from easyvista_python_client import EasyvistaClient, PostRequest