search

massenergize / frontend-admin

Frontend for the Admin Portal. This web interface is used by Community Admins (cadmins) to administer community-specific portals and by Super Admins to administer the entire MassEnergize web platform.
4 stars 3 forks source link

Scoping Out Progressive Templates #953

Open frimpongopoku opened 1 year ago

frimpongopoku commented 1 year ago

For explanation purposes, I am going to be referring to only "Actions". But, all the procedures I list here will be applicable to templates on Events, Communities, Teams, and any other items on the platform we want to work with.

@BradHN1, based on the explanation you gave in our last meeting, here is my understanding of how you need the "progressive" templates to work.

  1. You want admins/cadmins to be able to create actions from templates as they are already able to. But, you want the just-created action to be able to detect if there have been changes from the main template that it was created from.
  2. During detection, you want us to be able to ignore the parts of the action that have already been modified by the admin, and only deal with the parts that are still unchanged and match the initial structure from the template. With the unchanged fields, we want to prompt the admin of the new changes, and ask them if they would like to use the new values.

THIS IS HOW IT CAN HAPPEN (BACKEND)

We are going to need a new table: TemplateActionRel, and the action model would have a new field action_type whose value could either be empty, "SNAPSHOT" or "TEMPLATE".

_NB: This "actiontype" field wont alter how actions are working already. It will just help us weed out unnecessary items when we are listing actions to users.

TemplateActionRel

This table will be used to record the different states of a template as modified, and will also be used to create a relationship between a mother action, and all other actions that are created from it.

It will have the following fields: parent: Foreign key relationship to an action relationship: This value could be ("SNAPSHOT" or "CHILD") child : Foreign key relationship to an action

CASE 1 (Creating from template)

Now, if ActionB is created from already existing template ActionA, it will be recorded in this table as follows: parent: ActionA relationship: "CHILD" child: ActionB This setup above, is how we will know which actions were copied/created from which.

CASE 2 (Creating a new template)

Now, if an admin sends a request to create ActionC and marks it as a template, the following will happen.

  1. We will create ActionC and mark it as a template as we normally would.
  2. Then, using the same values that were used to create template ActionC, we will create another action -- ActionD _(with actiontype set to "SNAPSHOT")
  3. Then, we will add a new record inside TemplateActionRel table like this: parent: ActionC relationship: "SNAPSHOT" child: ActionD In this scenario, this record is not a parent-child relationship between actions, it is a record that links a parent template action, to one of it's states.

CASE 2 (Updating a template)

Now, if the admin comes back another time to update the template(i.e., ActionC) again:

  1. ActionC will be updated normally. Then another action (ActionE) will be created from the new updates of ActionC _(again, with actiontype set to "SNAPSHOT").
  2. After that, a new record will be created in TemplateActionRel once again like this: parent: ActionC relationship: "SNAPSHOT" child: ActionE This process will happen as described, every time a template is updated (ONLY TEMPLATES)

From the examples you can already see how easily we can find out the default, and the latest states of a template.

When we retrieve the snapshots of ActionC, we will get ActionD, and ActionE. Simply using the order in which all the snapshots were recorded, we can tell that ActionD is the default state that the template(ActionC) was created in, and ActionE is the latest state that ActionC is in.

DETERMINING CHANGES

Consider the actions in Case 1. In such a case, if we want to determine what has changed since ActionB was created from template ActionA:

  1. We would simply determine who the parent action of ActionB is, via the TemplateActionRel table.
  2. Then we would retrieve all the snapshot actions associated to the parent.
  3. Form there, we could easily determine the latest state of the template by just finding the latest snapshot of the parent that happened after the created_at date of the action in question(ActionB).
  4. And to find the initial state of the template that the action(ActionB) was created from, we would just find the latest snapshot of the parent template that comes before the "created_at" date of ActionB.

With these two retrievals, we could pass on the two snapshots to the frontend when an admin is editing ActionB. There on the frontend, we could easily map-out the fields and identify the changes. Then show the admin a nice notification of what changes there have been, if there are any...

NB: Once again, I am clarifying that I only make references to actions here, but the steps and logic could be followed to replicate the same effects on any other entities we have that require "progressive" templates.

frimpongopoku commented 1 year ago

@BradHN1, @Opoku-Agyemang , @abdullai-t