Class: Plutonium::Interaction::Async::RunPolicy

Inherits:
Resource::Policy
  • Object
show all
Defined in:
lib/plutonium/interaction/async/run_policy.rb

Overview

Authorization for run records themselves.

Named RunPolicy rather than Policy so ActionPolicy's ordinary inference finds it: INFER_FROM_CLASS looks for "#record_classPolicy", and Plutonium's STI fallback looks for "#base_classPolicy" — which is what routes a TestPostRun (or any host subclass) to this one policy without every subclass declaring anything.

Read-only

A run is the record of something that already happened. There is nothing to create through a form (a run is born from a dispatching interaction, which has its own policy), nothing to edit that would not be rewriting the audit trail, and deleting one destroys the only report of what a bulk action actually did. The four write predicates are therefore hard false rather than inherited defaults — subclasses can still open them, but they have to say so.

Scope

Nothing is declared here. The base policy's relation_scope already calls default_relation_scope, which applies Run.associated_with(entity_scope) — and that scope filters on the tenant the run RECORDED at dispatch (see Run). Re-declaring the macro to repeat that filter by hand would add a second, drifting definition of the same rule; declaring it as a def relation_scope instance method would be worse still, since apply_scope never calls one (Plutonium::Resource::Policy.method_added raises on that mistake at class load).

Instance Method Summary collapse

Methods inherited from Resource::Policy

#apply_scope, #default_relation_scope, #edit?, #export_csv?, #index?, #kanban_move?, method_added, #new?, #permitted_associations, #permitted_attributes_for_create, #permitted_attributes_for_edit, #permitted_attributes_for_export, #permitted_attributes_for_index, #permitted_attributes_for_new, #permitted_attributes_for_update, #reposition?, #search?, #send_with_report, #show?, #skip_default_relation_scope!, #typeahead?

Instance Method Details

#create? ⇒ Boolean

Returns:

  • (Boolean) 


37
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 37

def create? = false

#destroy? ⇒ Boolean

Returns:

  • (Boolean) 


41
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 41

def destroy? = false

#permitted_attributes_for_read ⇒ Object

Deliberately NOT the autodetected column list.

options is arbitrary JSON copied from the dispatching interaction's validated inputs — reasons, notes, recipient lists, whatever the author declared. The policy that governed who could SUBMIT those values was the interaction's; the set of people who can READ this run is different and wider (in a tenant portal, everyone in the tenant). Autodetection would quietly hand the second set the first set's input, so the readable attributes are enumerated instead, and options is not among them.

target_ids is out for the same reason at one remove: it is a list of primary keys that were never filtered through the target resource's own policy for THIS reader. outcome stands in for state, and state is deliberately absent: the two differ only for a run that completed having failed some of its targets, and that is precisely the case where the raw column reads "completed" and tells the reader the opposite of what happened.

errors_log is absent because the progress panel renders it as a list — the raw JSON column beside it would be the same report twice, once unreadably.



64
65
66
67
68
69
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 64

def permitted_attributes_for_read
  %i[
    type outcome progress_done progress_total
    target_label initiator started_at finished_at created_at
  ]
end

#permitted_attributes_for_show ⇒ Object

The show page drops the progress COUNTERS, for the reason errors_log is absent above: the panel already renders them, as "5 of 5 targets (100%)" over a bar. Two renderings of one number is the same report twice — and they disagree, because only the panel is inside the polled frame. A page that says "Completed" and "0 done" at once is worse than either alone.

The INDEX keeps them. There is no progress bar in a table row, so the counters are the only progress it can show.



80
81
82
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 80

def permitted_attributes_for_show
  permitted_attributes_for_read - %i[progress_done progress_total]
end

#read? ⇒ Boolean

Returns:

  • (Boolean) 


35
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 35

def read? = true

#update? ⇒ Boolean

Returns:

  • (Boolean) 


39
 
# File 'lib/plutonium/interaction/async/run_policy.rb', line 39

def update? = false