Subversion Repositories SmartDukaan

Last modification

• Rev 37685 2026-09-17 17:53:41
• Author: amit

• Log message:

  Remove selenium from the fofo portal entirely
  
  No browser starts in this WAR any more, and the selenium-java and
  webdrivermanager dependencies are gone with it. Verified: no source reference to
  selenium/WebDriver/ChromeDriver anywhere in the module, and zero selenium
  artifacts on the runtime classpath.
  
  Three pieces:
  
  1. The insights schedule and its pull move to profitmandi-cron (r37684) and dao
  (r37683). This service keeps only the READ paths -- redis, then in-memory,
  then cs.agent_daily_insight -- plus refreshInsights(), which now asks the dao
  sync service to run once and re-reads what it wrote. The portal therefore
  holds no credentials at all: KNOWLARITY_USERNAME/PASSWORD are deleted from
  this source, along with INSIGHTS_PAGE_URL and the 200-character CSS selector
  the scrape depended on.
  
  2. KnowlarityScraperService deleted. It was dead, not merely idle: zero
  references anywhere, both @Scheduled annotations commented out, and its
  @PostConstruct selenium block commented out with the note 'DISABLED - Live
  status now comes from WebSocket via profitmandi-cron'. SVN backs that up --
  r36057/r36058 (25-Mar) moved agent status to the websocket and r36072/r36075
  (26-Mar) created KnowlarityBreakLogService in dao, but nobody removed the
  corpse. It kept selenium in this WAR for six months after nothing used it.
  The data agrees: 'On Break - <reason>' rows in cs.rbm_break_log stop on
  25-27 March and plain 'Break' takes over, which is exactly that handover.
  
  ⚠ Consequence worth knowing: break-REASON granularity (lunch/meeting/sick)
  was lost at that migration and is not coming back from the websocket feed.
  
  3. setTokens() and POST /indent/set_knowlarity_tokens removed -- the method had
  already been reduced to a log line, and the pull now authenticates itself per
  run. Also retired the orphan knowlarity.scraper.enabled property (nothing read
  it; it was still 'true' in prod), and corrected a stale section header and a
  doc comment that promised 'current tokens' which no longer exist.
  
  Not touched, deliberately: POST update_agent_status / bulk_update_agent_status /
  update_status_by_name still exist and still write cs.rbm_break_log through
  AgentLiveStatusService. They are orphaned -- the deleted scraper was their only
  feeder and no view or script in the deployed WAR calls them -- but they are
  public HTTP surface, so proving there is no INTERNAL caller is not the same as
  proving no external one. Left for a separate decision.