Implement lg_attract_loop compatibility by adding GET args filters to queries

[mattjg908]

@mattjg908 commented on Mon Aug 15 2016

@wzin commented on Thu Jul 14 2016

Overview:

We want lg_attract_loop to show scenes that are inactive in ros_cms (e.g. are not shown on the touchscreen). lg_attract_loop fetches a list of scenes from the repository by adding attract_loop=true GET arg.

We basically want to be able to create screensaver presentations that are not avialable thru touchscreen. This is needed by UNC in the first place.

Requirements:

• add inactive=true|false (false by default) GET arg to repository API to be able to pull inactive scenes (do the same for presentations and presentation groups)
• add hidden=true|false (false by default) GET arg to repository API to be able to pull hidden scenes (do the same for presentations and presentation groups)

or

make attract_loop=true override active/inactive/hidden scenes and pull all scenes that are in attract loop.

( I personally like the latter more )

Testing scenario

• create a presentation with scenes that are supposed to be part of attract loop
  • have one presentation that's inactive and in attract loop
  • have one presentation that's hidden and in attract loop
  • have on presentation that's active and not hidden and in attract loop
  • have one presentation that's active and NOT in attract loop
• configure lg_attract_loop on the system (lg_attract_loop ros node + lg_activity - it's configured on tokyoros at the time of writing this issue)
• wait for system to go inactive
• observe first 3 presentations to be played back in attract loop

---

@eggyknap commented on Sat Jul 16 2016

The description above appears based on incorrect assumptions of how things actually function. Further, both the CMS and the description above are unclear on the precise meaning of the active and visible flags. I propose a different solution, therefore.

First, some background. In the CMS, users can mark one, and only one, presentation group as being the attract loop. The "presentation_membership" object, which links a specific scene to a specific presentation, has a "touchscreen visible" flag. Presentation groups, presentation memberships, and presentation group memberships (which associate a presentation with a group) have an "active" flag.

The description above says "We basically want to be able to create screensaver presentations that are not available thru touchscreen". It suggests we do this by modifying how we treat both the "active" and "visible" flags, but really we only the "visible" flag. An item not marked "active" should never be shown on the LG; that way a user can mark an object as not "active" when it's incomplete, or being worked on, or some such. This should apply both to the attract loop and to normal use. "Visible" is what we really want, to make presentations "not available thru touchscreen". So we need to add a "visible" flag to the presentation group membership.

I can't make the API just return everything when the attract_loop=True setting is in the URL, because the system doesn't return everything with only one GET request; instead, just like any other client of the CMS API, the lg_attract_loop node queries the system for the presentation group that has the attract_loop flag set, and then queries for objects within that group. The best way I can see to make this happen is as follows:

• Add a "visible" flag to the presentation group membership object. Queries for a presentation group with attract_loop=True should ignore this flag, but other queries to the director_api should honor it.
• Ensure the API endpoints for presentations and scenes allow GET requests to specify that they don't want invisible objects filtered out. Perhaps this will mean adding "visible=All" to the GET request
• Modify lg_attract_loop to use GET requests with this "visible=All" flag (or whatever parameter we finally settle on)

---

@wzin commented on Mon Jul 18 2016

+1 to this specification.

So we need to add a "visible" flag to the presentation group membership

I assume this means that we'll be able to have multiple (more than one) presentation groups included in an attract loop. We may want to need to include whatever subset of content in the attract loop, including presentationgroups thst are visible and invisible to touchscreen user. In shorter words - attract loop membership needs to be perpendicular (or independent) from visibility and still honor the active flag (thanks for pointing this out).

thanks for clarification - we actually have at least one customer that's waiting for this functionality so it would be nice to include it in 1.6.0 // cc @jausborne

---

@eggyknap commented on Mon Jul 18 2016

Yes, membership in the attract loop will still be independent of visibility. But your assumption is incorrect. The attract loop flag will still be on the presentation group object itself, and unless someone asks for it, we'll maintain the condition that at most one group has that flag set. If we start allowing multiple presentation groups in the attract loop, it will take reworking the lg_attract_loop node somewhat to support it, and we don't need to give ourselves extra work.

---

@eggyknap commented on Wed Jul 20 2016

3141396267349888f475e57bca2b9b9162b6eb86 fixes this as far as the CMS is concerned, but the solution given above requires changes to lg_attract_loop as well. @wzin, how do you want that handled?

---

@mattjg908 commented on Mon Aug 15 2016

Josh has implemented the CMS side of this, so I've moved it to the touchscreen

---

@axisofentropy commented on Mon Aug 15 2016

@mattjg908 The ROSCOE Attract Loop is currently implemented as a ROS node, so this should probably be moved to the lg_ros_nodes repository and assigned to its author Wojtek.

---

@mattjg908 commented on Mon Aug 15 2016

thanks @axisofentropy