Jump to content

MIS Linked Documents widget


gbligh

Recommended Posts

23 minutes ago, pconkie said:

The widget is ready and this is what you need in place asap so that it can start to capture the read receipts..  

@adamw I assume there won't be any issues with parents being able to save/update to the data-store? 

The app needs a group picker to be added - you have to type in a group uuid at the moment! Surely this is a re-usable component? Any tips from frog how to drop one in without reinventing the wheel?

Parents will need contribute rights to whatever site you put the widget on, in order to create datastore entries.

Honestly, I think we could do with having a good look at the datastore @Matt since its use now outstrips what it was originally designed to do. It seems to be a popular feature, so it may be worth looking into improving it. 

  • Like 1
Link to comment
Share on other sites

2 hours ago, gbligh said:

I might be being really basic here, but how do I actually get to it?!

I've missed 3 pages of conversation, so I could be missing something obvious,

The Frog MIS Linked Documents is within the Parent category of widgets and the FrogCode version is within the 'My Widgets' category

Link to comment
Share on other sites

1 hour ago, Simon Law said:

I've missed 3 pages of conversation, so I could be missing something obvious,

The Frog MIS Linked Documents is within the Parent category of widgets and the FrogCode version is within the 'My Widgets' category

I mean how do I run the reports as per @pconkie screenshot?

Thanks

Link to comment
Share on other sites

1 minute ago, gbligh said:

I mean how do I run the reports as per @pconkie screenshot?

Thanks

You need the updated widget in place (with contribute rights set for parents) to collect the data. 

You need a new app to select and view this data. The app isn’t ready yet!

Link to comment
Share on other sites

Ok, the app is ready.  Its nothing special (I haven't got any more time to work on it) but should give you a basic report if you select a year group/tutor group/house and then type in the name of a report.

Link to comment
Share on other sites

9 hours ago, pconkie said:

Ok, the app is ready.  Its nothing special (I haven't got any more time to work on it) but should give you a basic report if you select a year group/tutor group/house and then type in the name of a report.

Thanks Paul - I thought I was missing something!

Link to comment
Share on other sites

53 minutes ago, Graham Quince said:

Once again, thank you Paul.

I've grabbed the reporting app, but I'm on a train - so no promises in getting it avaialble today.

You off somewhere nice........................................ :frog319!!!

  • Haha 1
Link to comment
Share on other sites

On 26/06/2019 at 10:09, Graham Quince said:

Once again, thank you Paul.

I've grabbed the reporting app, but I'm on a train - so no promises in getting it avaialble today.

Hey Graham - could we get that app?

cheers 

Link to comment
Share on other sites

There has been a change to the frogcode datastore api that has stopped this widget from working.

I hope it is just a bug inadvertently introduced in Frank as it has also broken several other widgets....

Here is an example...

Capture.PNG.2f33b30ee0365e481fbf93d4ea82b6d8.PNG

Yesterday, if you supplied a user_uuid (as I am doing above in the params section) this is what was saved. Today, it is getting ignored and being replaced with the uuid of the currently logged in user (this is why created_by and user_uuid are the same in the response section).

@adamw @Matt @Graham Quince 

Please help!

Link to comment
Share on other sites

2 minutes ago, pconkie said:

There has been a change to the frogcode datastore api that has stopped this widget from working.

I hope it is just a bug inadvertently introduced in Frank as it has also broken several other widgets....

Here is an example...

Capture.PNG.2f33b30ee0365e481fbf93d4ea82b6d8.PNG

Yesterday, if you supplied a user_uuid (as I am doing above in the params section) this is what was saved. Today, it is getting ignored and being replaced with the uuid of the currently logged in user (this is why created_by and user_uuid are the same in the response section).

@adamw @Matt @Graham Quince 

Please help!

Hi - i'll try to get some help on this, Adam isn't available this week.

Link to comment
Share on other sites

1 minute ago, Graham Quince said:

Hi - i'll try to get some help on this, Adam isn't available this week.

Thanks Graham.  I just checked the other widget that works in the same way and it still works?!

Wondering now if it's a complex permissions issue and not a bug? 

For context, the current user has a parent profile (parents have contribute permissions on the page).

The user_uuid we are passing is the uuid of one of their children (students do not have any permissions to the page this widget is on)

Could it be the case that parents need greater permission in order to save a uuid other than their own? Or perhaps students need at least some permissions?

 

When I log in with an admin account (edit and manage permissions) I can add my "child's' uuid! Would be a real shame if we needed to give parents edit and manage permissions in order for this to work!

Link to comment
Share on other sites

PS: I gave the test parent account temporary edit and manage permissions to the site and they still couldn't save anything other than their own uuid.  Please could we consider this use case and the others like it where, it would be useful for us to have a parent record they have done something for one of their children?

Link to comment
Share on other sites

Hi there! I'm one of Adam's colleagues, I've just been given this datastore problem to look at.

You're right that it's a permissions issue; at present, only admin and staff profile types can set the user_uuid to a custom uuid. It's fairly strightforward to make this configurable in groups and policies, so I'll add it to my worklist and let you know when it should be available.

As an aside; when you want to give us a copy of the response to look at, take a look at the "Response" tab in development tools "network" section. It's next to the "preview" tab you're currently using, and means we can get the actual text.

  • Thanks 1
Link to comment
Share on other sites

19 minutes ago, simon brahan said:

Hi there! I'm one of Adam's colleagues, I've just been given this datastore problem to look at.

You're right that it's a permissions issue; at present, only admin and staff profile types can set the user_uuid to a custom uuid. It's fairly straightforward to make this configurable in groups and policies, so I'll add it to my worklist and let you know when it should be available.

As an aside; when you want to give us a copy of the response to look at, take a look at the "Response" tab in development tools "network" section. It's next to the "preview" tab you're currently using, and means we can get the actual text.

Thanks @simon brahan It feels like this is something that would be incredibly useful moving forward, so thank you for adding it to your (no doubt long) list of things to do!  

@gbligh be aware that the linked document widget won't collect the data required for the app to show you read receipts until we get this sorted.

Link to comment
Share on other sites

Hi everyone,

I've been sitting with @simon brahan and if i understand this correctly, technically we can turn on the ability for parents to view and manage all entries in the datastore.  But this would be global and so we're a bit uncomfortable doing this.

Each parent already has the ability to write their own entry to the datastore, rather than editing the single shared entry as it is now. Admins can still read all entries.   It feels A LOT safer to use this option. 

 @pconkie - how does that option sound to you?  I can probably get you some help/advice to rewrite the widget if you need it?

Link to comment
Share on other sites

@Graham Quince I'm not sure I really follow.

Yes, parents can currently write entries to the datastore, but only about themselves and not about their children.

If they could write an entry regarding their child, it would still be 'theirs', no? I suppose you would need to implement a sort of "is this parent user the user who created this entry [created_by_uuid] or do they have a relationship to the user for whom it is about [user_uuid]" logic. If that logic isn't in the codebase then I think it should be considered. But if it's not, then I also agree there is no quick fix as it would inappropriate to grant 'global' read/write.

We really need to work from lists of students (not lists of parents) with this - i'm struggling to work out how the app and widget can be re-written? I assume if the child has two parents and they both read the report the datastore will not allow for one parent to edit an entry made by the other(?) and there will therefore bu multiple entries relating to a single child.

What I think you are suggesting would be very cumbersome - we would have to search through every datastore entry for a particular report looking in the data field for a child's uuid.  We would have to check them all, even if we found one because there could be multiple parents.

So if we wanted a year group list (say 300 in a year group) and there were 500 entries for that particular report in the datastore.  This would involve doing 150,000 checks before rendering the list. Probably should avoid this.  If there is a way to return the members of a group with associated parent uuids then we could use an associative array to directly access the related parent views and avoid all that looping/checking. Is this possible? 

Link to comment
Share on other sites

Hi again @pconkie.

I've grabbed a copy of your code from Graham to take a look at what you're doing and how it could work with the current restrictions of the data store.

In your widget you're storing the read around line 111:

record.data.push({parent:currentuser.displayname,envir:environment,datetime:moment().unix()});

In your app you're fetching all the report data and grouping it by user uuid around line 68:

this.receipts[response.response[i].user_uuid] = JSON.parse(response.response[i].data);

What if you added the child uuid to the payload content:

record.data.push({parent:currentuser.displayname,envir:environment,datetime:moment().unix(),child:active_child});

Then you could group by that when you fetch the results:

var data = JSON.parse(response.response[i].data);
this.receipts[data.child] = data;

Would that work?

Link to comment
Share on other sites

24 minutes ago, simon brahan said:

Hi again @pconkie.

I've grabbed a copy of your code from Graham to take a look at what you're doing and how it could work with the current restrictions of the data store.

In your widget you're storing the read around line 111:


record.data.push({parent:currentuser.displayname,envir:environment,datetime:moment().unix()});

In your app you're fetching all the report data and grouping it by user uuid around line 68:


this.receipts[response.response[i].user_uuid] = JSON.parse(response.response[i].data);

What if you added the child uuid to the payload content:


record.data.push({parent:currentuser.displayname,envir:environment,datetime:moment().unix(),child:active_child});

Then you could group by that when you fetch the results:


var data = JSON.parse(response.response[i].data);
this.receipts[data.child] = data;

Would that work?

Assuming both parents independently read the report we might lose the first parents data when we group the data in the app.  But we should be able to do something about that...

Yes, I think this a really good suggestion, thanks.

Link to comment
Share on other sites

16 minutes ago, pconkie said:

Assuming both parents independently read the report we might lose the first parents data when we group the data in the app.  But we should be able to do something about that...

Yes, I think this a really good suggestion, thanks.

No problem. I'll keep this thread open, let me know if you need a hand with anything.

Link to comment
Share on other sites

Rather than this:

var data = JSON.parse(response.response[i].data);
this.receipts[data.child] = data;

This seems to work:

var data = JSON.parse(response.response[i].data);
if (data[0].child in this.receipts) {
  for (var x = 0; x < data.length; x++) {
    this.receipts[data[0].child].push(data[x]);
  }
} else {
  this.receipts[data[0].child] = data;
}

However, the receipts are not necessarily ion chronological order now, so we need to do a sort at some point...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...