Skip to content

Conversation

@ofedoren
Copy link
Member

The idea is that we look at the events the template will be used for and try to find back the model which supports this event. Then we take a sample of a model object from DB and run the rendering against that object. This also implies that preview button will be visible only for the templates which are assigned to at least one webhook.

We don't need any mock object since the object itself is valid and contains Jail subclass, so we can preview in safemode.

Unfortunatelly, I didn't find how we would mock an Action object, so that's in TODO if there is any way. Any idea @adamruzicka ?

@ofedoren ofedoren force-pushed the feat-33691-make-preview-work branch from 02bf1be to 44c6d03 Compare August 21, 2024 13:39
Copy link
Contributor

@adamruzicka adamruzicka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was an interesting read, sorry for not getting to it earlier.

The idea is that we look at the events the template will be used for and try to find back the model which supports this event. Then we take a sample of a model object from DB and run the rendering against that object.

What if the user can't currently see any such resource?

This also implies that preview button will be visible only for the templates which are assigned to at least one webhook.

This might cause some friction. It would mean that if I were implementing a new webhook template, I would have to have a webhook with it, meaning it could fire while I'm still working on it, wouldn't it?

We don't need any mock object since the object itself is valid and contains Jail subclass, so we can preview in safemode.

What would we do with events which don't get a full object, such as build_entered https://github.com/theforeman/foreman/blob/4825e9e34df5469fdd8e091285d7c2c1e96718ef/app/models/host/managed.rb#L51 ?

Unfortunatelly, I didn't find how we would mock an Action object, so that's in TODO if there is any way.

We would have to dive a bit into dynflow internals, but it should be doable. For "$action stopped" and so on we would have to decode the event name into an action name, look up all the tasks with matching label, pick on and then pull its entry action for presentation with https://github.com/Dynflow/dynflow/blob/93060070e6169af7a27b3821942880c336a91b87/lib/dynflow/persistence.rb#L33

model = id_event_model[:model]
# TODO: Find a way to get a sample for Actions
# RANDOM() works only on PostgreSQL
object = model < ApplicationRecord ? model.order("RANDOM()").limit(1).first : model
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this consider permissions?

# RANDOM() works only on PostgreSQL
object = model < ApplicationRecord ? model.order("RANDOM()").limit(1).first : model
context = ::Logging.mdc.context.symbolize_keys
# TODO: Waits for Ruby 3.1+ syntax
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, what does 3.1 bring in term of syntax?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants