consected / restructure Goto Github PK

Issue described in https://nokogiri.org/CHANGELOG.html#1139-2022-10-18

Update Gemfile to lock nokogiri to version 1.13.9

See README.md where the zeus config is imported after creating an admin user.

(Reported by Felix)

For example, a common routing error causes a full stack trace to be recorded in the log file

F, [2023-01-09T09:22:04.400166 #27711] FATAL -- :   
F, [2023-01-09T09:22:04.400234 #27711] FATAL -- : ActionController::RoutingError (No route matches [GET] "/autodiscover/autodiscover.json"):
F, [2023-01-09T09:22:04.400251 #27711] FATAL -- :   
F, [2023-01-09T09:22:04.400273 #27711] FATAL -- : vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/debug_exceptions.rb:65:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
vendor/bundle/ruby/2.7.0/gems/railties-5.2.8.1/lib/rails/rack/logger.rb:38:in `call_app'
vendor/bundle/ruby/2.7.0/gems/railties-5.2.8.1/lib/rails/rack/logger.rb:26:in `block in call'
vendor/bundle/ruby/2.7.0/gems/activesupport-5.2.8.1/lib/active_support/tagged_logging.rb:71:in `block in tagged'
vendor/bundle/ruby/2.7.0/gems/activesupport-5.2.8.1/lib/active_support/tagged_logging.rb:28:in `tagged'
vendor/bundle/ruby/2.7.0/gems/activesupport-5.2.8.1/lib/active_support/tagged_logging.rb:71:in `tagged'
vendor/bundle/ruby/2.7.0/gems/railties-5.2.8.1/lib/rails/rack/logger.rb:26:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/request_id.rb:27:in `call'
vendor/bundle/ruby/2.7.0/gems/rack-2.2.5/lib/rack/method_override.rb:24:in `call'
vendor/bundle/ruby/2.7.0/gems/rack-2.2.5/lib/rack/runtime.rb:22:in `call'
vendor/bundle/ruby/2.7.0/gems/activesupport-5.2.8.1/lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/executor.rb:14:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/static.rb:127:in `call'
vendor/bundle/ruby/2.7.0/gems/rack-2.2.5/lib/rack/sendfile.rb:110:in `call'
vendor/bundle/ruby/2.7.0/gems/actionpack-5.2.8.1/lib/action_dispatch/middleware/ssl.rb:74:in `call'
vendor/bundle/ruby/2.7.0/gems/railties-5.2.8.1/lib/rails/engine.rb:524:in `call'
vendor/bundle/ruby/2.7.0/gems/puma-6.0.2/lib/puma/configuration.rb:268:in `call'
vendor/bundle/ruby/2.7.0/gems/puma-6.0.2/lib/puma/request.rb:93:in `block in handle_request'
vendor/bundle/ruby/2.7.0/gems/puma-6.0.2/lib/puma/thread_pool.rb:340:in `with_force_shutdown'

The desired approach is just to record a simple WARN line without stacktrace.

Link from user role in each role to the access controls for the role

Link from username to user profile

Hide users that have been disabled

Change the user drop down to allow typeahead

Copy from one role to another

• allow typeahead in drop downs
• remove disabled users from the target
• allow copying even if a user has roles already - then list the actual roles added

For example, APIs will want to use things like '&client_secret=' in a URL or header.

Prefer an approach that does not require rebuilding the app, or using ENV variables (as AWS limits space on these).

Consider a pluggable approach with one plugin that gets secrets from AWS secrets manager, on demand and cached.

The item flags are not exported or imported in the Admin::AppType class

Transfer changes related to template versioning, improved specs and documented code

Many corporate users have email addresses that appear with uppercase username. All usernames in ReStructure are stored as lowercase. The username should be downcased (on the client?) in order to avoid confusion

Need to either scroll to a flash if present, or make flash fixed position.

Fails with viva variable view in data dictionary

Had to do this instead

dcmodify -i "(0010,0010)=ABC" xrayimage2.dcm
dcmodify -i "(0010,0020)=ABC" xrayimage2.dcm
dcmodify -i "(0008,0020)=20210101" xrayimage2.dcm

then move to overwrite the broken reidentified images.

Just run psql then the create database... command.

README requires an update

For example placeholder_proposal_details

This is probably due to the ordering of the handlebars processing of fields.

How to reproduce

Add a new report

Add a simple SQL query in the SQL block:

select * from player_infos where first_name = :names;

Add a search attribute by clicking Add attribute

• Name: names
• Type: config selector
• Single or multiple values: single
• Config selections:

phil: phil
bob: bob

• Default: phil

Add the attribute then check the default, by clicking the names tag that appears under the search attributes label

The default is incorrect.

Now try this for:

• Single or multiple values: multiple (in)

The search value is retained correctly.

An admin wants to be able to schedule actions that occur once a day, at a certain time of day. These actions could be provided by something similar to the save_trigger actions in dynamic definitions, providing a series of actions to be performed against a record if certain conditions are met.

Rather than actions being triggered by saving or creating a record, a batch of records would be run through when scheduled, the existence of each record firing the trigger. Every record in the dynamic model would be tested against an "if" condition, then the following trigger actions would be run (each of these could have its own "if" conditions)

The dynamic model could be represented by a regular table, potentially populated by an external process, allowing schedule responses to be performed against externally generated data. Or a view SQL definition within a dynamic model could be used, allowing a completely dynamic batch to be defined.

The addition of the following would define the batch_trigger mechanism in a dynamic model, external identifier or activity log:

default:
  # ...
  batch_trigger:
    - if:
        always: true # for example...
      then:
        - add_tracker:
        - notify:
        - add_tracker:
        - create_reference:
    

Notice the list array in "then:" block, allowing for defined ordering of actions, with the potential to repeat actions with the same name. An alternative definition might use a simple hash here if ordering is not required.

The above is perhaps idealistic. A simpler implementation would be to use an exact copy of the save_triggers:

default:
  # ...
  batch_trigger:
    on_record:
      notify:
      add_tracker:
      create_reference:
    

Also, this may have broken Report fields that can be filtered (domain / subdomain in analysis projects for example)

It should:

• pull data using the existing pull_reference_data capability
• identify the array of hashes that represent the data record set in the result, using a simple key1.key2.key3 type "dig" notation (we've used this in substitutions already I think)
• configure the model to write to
• handle upsert to the model, on an identified key field
• limit the fields that are captured (possibly an array of field names, or a hash mapping target_field: source_field)
• capture each record result within its own transaction, since save triggers will be fired, and we don't want successfully entered data to be rolled back unnecessarily

Also look at the save trigger update_reference how to identify the target model and handle forcing updates, even if ACLs don't allow.

Additional considerations are how to handle paged resultsets, but this is not a priority.

Binary data, for JSON text upload for example, and headers to allow things like Content-Type to be set