Skip to content

Milestones

List view

  • It should be possible to upgrade a running process instance, in production, to use an updated version of the Process Model. This is a placeholder for more tasks - but wanted to capture the requirements * Must function in production * Allow updates to all "down-stream" changes to the process model - that is activities that would happen in the future * 1 upgrade at a time is acceptable, though bulk conversions in the future is highly desired * Ability to save the current instance and revert back to it in the event that the migration fails for some reason * Migration should be logged - so it is recorded when a migration was applied in the history of events * Data is preserved - the Timestamps of completed tasks, task data, and data objects Time Line - Would like to have this completed over the next month (end of June) if at all possible but there is not a definitive timeline.

    Overdue by 1 year(s)
    Due by July 30, 2024
    2/2 issues closed
  • Imagine having the ability to select a call activity process, then complete a form to specify what input to send to it. For instance, a call activity that handles "API calls to Slack". When you add it to the diagram, and click "configure" you get dropdown list of "Send" or "Read" and when you select send, you can select the channel you want to send to from a known list. We can do this by specifying a Json Schema on a Data Input object. Json Schemas on Workflow Data (data inputs, outputs, objects, stores) has the following benefits: * The json schema can be used to generate a form when adding a Call Activity to a process. * It can perform run-time validation so we get detailed errors back when the data supplied to a call activity is invalid * Testing Call Activities independently becomes far easier because we can just submit several different values into the form. # Example: Alex writes: regarding the example for 'schemas on data inputs and outputs #1179', the example I showed during the meeting can be found here: https://dev.app.spiff.status.im/process-models/misc:service-tests:iplicit:maintain. As I briefly mentioned that current example allows you to select which Iplicit action, GET, DELETE, PATCH, etc., you are intending to use and for the Call Activities each would be a separate json schema for each Iplicit Category, i.e., Catalog, ContactAccount, Department, etc., instead of all being in one schema as they currently are found. This is part of the additional work that I mentioned at the beginning of the meeting and received Sasha and Marius' approval to work on as time allows. I have already start this work by breaking out the json schema for GET, which can be found here (https://dev.app.spiff.status.im/process-groups/misc:service-tests:iplicit:methods:contactaccount).

    No due date
    0/1 issues closed
  • Assure that Messages are working consistently and effectively. This is not adding any features, but it does include changes to the backend, library, ui, and bpmn.io to make it moderately intuitive how you can apply messages, and track their path through the system.

    No due date
    9/18 issues closed
  • - The set of tickets outlined in the "QA And SpiffWorkflow" document, it's aim is to improve the tools that BPMN Authors and our QA team can use to exercise BPMN process models. This phase 1 effort will largely focus on unit tests - a way to define a script that we can use to run the BPMN diagram in isolation.

    No due date
    5/10 issues closed
  • We have a proposed UI/UX design from Eli. This will hold the tickets required to implement this refactor and drastically improve the overall experience for most users.

    No due date
    15/18 issues closed
  • These tickets replace our background processor with a queuing system which should drastically improve the background processor, the granularity of timer events, and the overall stability of the system. The Queue will be fast enough for progress to be polled by our interstitial page, making it faster and removing some bugs around it.

    No due date
    10/16 issues closed
  • The smallest amount of work that will allow us to provide a Bounty system for GitHub Issues. This should focus on a workflow process and whatever minor additions or enhancements to SpiffWorkflow that would be required to allow external users to request an Issue assignment, submit that assignment, and collect the reward.

    No due date
    10/13 issues closed
  • Tickets to support building an IRB prototype based on CRC2 features.

    No due date
    1/2 issues closed