Open TL41 opened 10 months ago
Access log would be a good table to source this, however we would need to remove entries which are irrelevant (i.e. to sections opening) and also to pages which are more 'ephemeral' (i.e. flow registration pages).
There are a few ways to tacke this. As an experiment I wrote a little bit of sql (below) to see if we could get the access log to look more like a list of entity references. This relies on a bit of json parsing (json_extract_path
) which is specific to postgres and we would need to see how to emulate on mssql.
Once we have the list of references we can use the existing InlineSelectFieldFactory
to resolve the refs to names/descriptions.
with statemap as (
select *
from (values
('main.actor.view', 'ACTOR'),
('main.app.view', 'APPLICATION'),
('main.app-group.view', 'APP_GROUP'),
('main.change-initiative.view', 'CHANGE_INITIATIVE'),
('main.database.view', 'DATABASE'),
('main.data-type.view', 'DATA_TYPE'),
('main.flow-classification-rule.view', 'FLOW_CLASSIFICATION_RULE'),
('main.flow-diagram.view', 'FLOW_DIAGRAM'),
('main.legal-entity-relationship.view', 'LEGAL_ENTITY_RELATIONSHIP'),
('main.legal-entity.view', 'LEGAL_ENTITY'),
('main.licence.view', 'LICENCE'),
('main.logical-flow.view', 'LOGICAL_DATA_FLOW'),
('main.physical-flow.view', 'PHYSICAL_FLOW'),
('main.physical-specification.view', 'PHYSICAL_SPECIFICATION'),
--('main.report-grid.view', 'REPORT_GRID'), -- tricky as not a single identifier
('main.server.view', 'SERVER'),
('main.survey.instance.response.view', 'SURVEY_INSTANCE'),
('main.survey.run.view', 'SURVEY_RUN'),
('main.survey.template.view', 'SURVEY_TEMPLATE')
) statemap(state, kind)),
raw_latest as (
select distinct state, params
from access_log
where user_id = 'admin'
and state not like '%|%'
and state not like 'embed%'
and state not like '%edit'
limit 50)
select s.kind, json_extract_path(params::json, 'id') as id
from raw_latest r
inner join statemap s on s.state = r.state;
Description
Currently, if a user clears their browser cache or switches to another browser / client where that data isn't carried over, then the list of 'Recent' items is not populated or does not reflect all of the users true browsing history.
The suggestion would be sourcing this info from an existing table (access_log?)
From what I can see in access_log, we would probably need to filter specific and distinct states / params combinations that are valid for display in recents
Initial Priority Assessment: "nice-to-have"
Resourcing
We would like to collaborate on this feature