[MGNLRES-342] Resources-app - displaying wrong resource origin Created: 25/Nov/19  Updated: 29/Mar/22  Resolved: 05/Jan/20

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: 3.0
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Christoph Meier Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Team: Nucleus

 Description   

Context - Displaying the origin of the resource

In the resources app, a resource's origin can be:

  1. File system
  2. Java classpath
  3. JCR

(1), (2) are frequently occurring.
(3) is a result of: edit resource (a hotfix of a resource originating from file or classpath), add resource, upload file or add folder.
The issue appears after deleting JCR based resources.

Reproducing the issue(s)

Example scenario - part 1

  • Have a light-module foobar-module (on the file system) 
  • In the resources app:
    • Add the folder static
    • within static, upload a file lala.pngs and Add a file solala.yaml
    • repeat the 2 steps above within mtk

The new resource(s) static/, static/lala.png and static/solala.yaml are all marked as origin from JCR.
That's correct.
Also the parent folders fobbar, mtk are marked as origin from JCR ... which is arguable .. but "understandable".

Example scenario - part 2

Now delete the created resources (/static/*) from above. (Currently you need the JCR app for this, see MGNLRES-341.)

In consequence, the resource should be "back to normal", showing the same origin as they had showed at the very beginning of the scenario. For instance,

  • /foobar-module should show the "File system" origin
  • /mtk should show the "Java classpath" origin
    However ... both these folders still "claim" (show) to be of "JCR" origin, which is wrong.


 Comments   
Comment by Aleksandr Pchelintcev [ 05/Jan/20 ]

The problem lies in the fact that the sample resources are deleted via JCR browser app, which is not intended way of working with resources: specific resource deletion action would also recursively erase the folder nodes in case no JCR resources are present in them any longer. In the described scenarios the hotfixed folder nodes remain, which is properly indicated by the UI.

Generated at Mon Feb 12 06:49:45 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.