Object Edit "Proposals"

Ask the Community
1

I have objects to which I would like users without full edit permissions to be able to “propose” edits.

How can I model this in the Ontology?

Something like this isn’t a first-class concept in Foundry, but how could I create a workflow that accomplishes this user workflow?

2

Hey, there are two primary ways to model this.

The first (simpler but less functionality) way is to have a status property on your primary object type. You can then have another property that represents a proposed edit. When the user makes an edit, the edit gets written to the proposed edit property. In that same action, the status is set to “proposed” or something. Next, a user with elevated perms can come in and “approve” that proposal, which will update the status property and set the main property to the current value of the proposed edit.

  • This is easy to set up but has some disadvantages
    • First of all, you need to create a proposed edit property for each property that needs to support proposals
    • Secondly, you can’t have multiple concurrent edits at the same time.
    • Next, its harder to capture edit metedata such as who proposed it, who approved it, and when. You can use action logs, but its not ideal.
  • All that being said, this method is very easy to set up and if you need something quick and simple, this may work for your use case.

The more advanced method for proposals is to create a proposal object. This object would have the same shape in terms of properties as the base object, with some added properties such as a proposal status, timestamp, author, reviewer, and a foreign key to the main object. In this approach, every time a user wants to make an edit to the main object, an action creates a new proposal object. Next, a user with elevated permissions can come in and approve the proposal object, which will edit the linked base object and set the status of the proposal to “approved”.

  • The main advantages to this flow is that you can have multiple proposals for the same object, its more maintainable / scalable, and you get a nice change history object out of the box by filtering your proposal object type down to the approved objects.
  • Also having separate objects for your proposals vs your main objects is a bit more secure and easy to manage.
  • It is a bit more work to set up, but if you need an advanced proposal flow, its probably worth it.

To see an example of an advanced proposals flow, try out the Foundry rules app.

3

That makes a lot of sense - both solutions.

Things become even more challenging when a “Proposed Change” actually corresponds to multiple objects. An example here is a Purchase Order, Purchase Order Line Item, and Purchase Order Fees. You may be semantically proposing a change to an overall PO, but technically, under the hood, it is to a grab bag of the linked entities.

Does that example make sense? How might you extend your second proposal with that in mind?