When I using the api /schedule/data/events return a empty object.
I dont know if i doing something wrong.
thanks for your help.
Assuming that display group id 3 is either an actual display group or display specific display group and that in the specified timetable there are some events scheduled then I can see one thing that you’re missing there.
displayGroupIds is an array of integers ie it should be something like:
{{url}}/api/schedule/data/events?displayGroupIds[]=3&from=1477414800000&to=1477936800000
in short, you’re missing [] after displayGroupIds in your call
Help me please, I am stuck. I’m trying to use same call to schedule/data/events (Xibo v1.8.7) but I can not figure it out. I have tried postman and Xibo oAuth2 client.
I have events scheduled for specified time frame; see below call /schedule/15/events
The solution in Postman was to provide displayGroupIds[] with a lowercase ‘D’ instead of how the ‘DisplayGroupIds[]’ was specified in Swagger UI documentation. See posted answer get-scheduled-events-api-seems-to-be-broken-1-8-0-alpha2.
I am still stuck with with the oauth2-xibo-cms schedule/data/events API call failing in the class XiboSchedule.php. It fails with following error on statement $this->hydrate($item) statement.
TypeError Exception: Argument 1 passed to Xibo\OAuth2\Client\Entity\XiboEntity::hydrate() must be of the type array, integer given, called in /var/www/cms/vendor/xibosignage/oauth2-xibo-cms/src/Entity/XiboSchedule.php on line 45
/**
* @param array $params
* @return array|XiboSchedule
*/
public function get(array $params = [])
{
$entries = [];
$response = $this->doGet($this->url2, $params);
foreach ($response as $item) {
$entries[] = clone $this->hydrate($item); //<<<<< **TypeError thrown here**
}
return $entries;
}
Few things to clarify here.
parameter name, it is indeed displayGroupIds, documentation is wrong with the capital D there.
Now, schedule API in general.
/schedule/data/events - all the code that is executed there is mainly to draw the calendar and events on it (in webui), as such it is not perfect for API, however in postman the results should be correct with displaygroupIds[] and to from provided.
/schedule/{displaygroupId}/events
That is mostly for Agenda view, but you can get event information via API as well.
OAUTH2
There are severe changes coming to our ouath2 and wrappers, as it stands there will be a work around for the way schedule is currently working, in the future, we will need to make changes in the core CMS code and create a new route for the API schedule calls.
The hydrate() in Xibo entity is expecting an array, which is true for pretty much all get calls in CMS, however due to mentioned schedule structure and the fact that it is written mainly for the calendar / agenda view, the results you get from API will not be entirely correct.
Basically, if you look at your postman calls you get the success : 1 and then an array of results, if you use the wrapper as it is now, it basically will try to pass 1 (from success) ie integer as a first parameter to the Hydrate() which will trigger the error you mentioned.
Something like that should work
/**
* @param array $params
* @return array|XiboSchedule
*/
public function get(array $params = [])
{
$entries = [];
$response = $this->doGet('/schedule/data/events', $params);
foreach ($response['result'] as $item) {
$entries[] = clone $this->hydrate($item);
}
return $entries;
}
It is also possible that not all parameters are correctly listed in the XiboSchedule wrapper, as such the entries for this call might not be populated entirely well.
I recall changing that as well, I’d suggest to hold off using GET schedule wrappers until I sort it out in my branch.
With what I currently have in my local oauth2 branch, I can get the following from GET wrapper:
[id] => 49
[title] => phpunit layout scheduled on phpunit displaygroup
[url] => /api/schedule/49
[start] => 0
[end] => 2147483647000
[sameDay] =>
[editable] => 1
[event] => Array
(
[eventId] => 49
[eventTypeId] => 1
[campaignId] => 89
[commandId] => 0
[displayGroups] => Array
(
[0] => Array
(
[displayGroupId] => 15
[displayGroup] => phpunit displaygroup
[description] => phpunit displaygroup
[isDisplaySpecific] => 0
[isDynamic] => 0
[dynamicCriteria] =>
[userId] => 1
[tags] =>
)
)
[userId] => 1
[fromDt] => 0
[toDt] => 2147483647
[isPriority] => 0
[displayOrder] => 0
[recurrenceType] =>
[recurrenceDetail] =>
[recurrenceRange] =>
[recurrenceRepeatsOn] =>
[campaign] => phpunit layout
[command] =>
[dayPartId] => 4
[isAlways] => 1
[isCustom] => 0
[syncTimezone] => 0
)
Which is what we want, but as it does require a bit of tinkering I’d wait for my next commit to oauth2 or even better for it to be ‘complete’ and merged with project oauth2 branch.
How much time until you get your branch sorted out? As you said “I’d
suggest to hold off using GET schedule wrappers” (Mar 13, 2018 5:32 AM,
Peter). I would need to weigh against our initial software release schedule
to make an informed decision.
Thanks a lot. Your clarifications have definitely helped!
That is a good question, I will probably make some commits this week to my branch of our oauth2, as I have a lot of changes in my local branch already.
It should include implementation of a logger interface, logs and various fixes/additions to the wrappers (including fixes for GET schedule wrappers).
I also have rewritten simple.php I will make sure to include lines that should help everyone identify the structure of responses in Schedule GET wrappers (and other wrappers as well).
That file will be reworked in the future, but as a intermediate solution it could be helpful, as such I will include it in my next commits.
My oauth2 branch also has the league/oauth2-client updated to the 2.2 version (the one in our main repo is based on 1.0), as such there are some additional changes made there and it does require php 5.6 or later.
There are more changes in my oauth2 project coming in the future, but it would be hard for me to give you an estimate on those at the moment.