Uploaded image for project: 'mod-inventory-storage'
  1. mod-inventory-storage
  2. MODINVSTOR-70

hierarchical location structure and endpoint

    XMLWordPrintable

Details

    Description

      This a backend prerequisite for the model of "locations" as described here UIORG-45

      marcjohnson nielserik guys I am putting this under mod-inventory since this is where the "old" flat locations live.

      It seems that the most trivial implementation is something along the lines:

      collection: /locations
      item: /locations/{id}
      
      Location.json
      {
        "id": "UUID"
        "name", "Miller General Stacks",
        "code" : "UA/CB/LC/GS", //unique
        "status": "active" | "inactive, //maybe boolean is better here
        "institution": "X",  
        "campus": "Y",
        "library": "Z", //all three should be controlled values
        "parking": {"a":"b", ...} //kv pairs, it's an object rather than an array since keys should be unique
      }
      
      We need also a set of services for controlling inst/camp/lib values and their hierarchy, e.g
      
      collection/item: /org/institutions/{id}
      collection/item: /org/campus/{id}
      collection/item: /org/libraries/{id}
      
      and lower-level item structure tpoints to the higher level, e.g
      
      Campus.json
      {
         "id": "UIID"
         "name": "Campus 1"
         "institutionId": UUID //points to parnent institution
      }
      
      Library.json would be similar.
      
      This structure is clearly repetitive, so it might make sense to have a generic recursive structure for this (e.g Unit.json)
      
      Also, notice that in Location.json we can either use UUIDs for inst/camp/lib, though preferably we would use name/values directly and validate behid the scened. It would make the input method described in UIORG-45 much simpler.
      
      

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                heikki Heikki Levanto
                jakub Jakub Skoczen
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 1 week, 4 days, 2 hours, 15 minutes
                    1w 4d 2h 15m

                    TestRail: Runs

                      TestRail: Cases