adamw

There's probably a better way, but a quick look at the API's show that a call to users.getSummary with a param of { profile: 'profile-student' } Should get you something back for every student - you can then look in the details section that comes back with every user: "details": { "forename": "Fname 3", "surname": "Sname 3", "thumbnail": null, "gender": null, "mis_linked": false } I don't have time to knock together a widget at the moment to do this - and like I say, there may be a more efficient way using different api's - perhaps the ones to find users extended data. I'll keep an eye out for a better way! In the meantime, I know @Graham Quince is always chomping at the bit for new widgets to make ?

I will have a look at the API's and see if there's an easy way. Not something I've considered before!

I wasn't directly involved in this, but I imagine this is a security precaution (and quite a common one too). By showing the email address when a user puts their username in, you're potentially exposing that information to a malicious user. For example, if all your usernames follow a certain format, then someone could use that to get the email addresses of all your users, simply by guessing usernames. The same could be said for the other way around - if you know someone's email address then you can get the system to tell you their username. By not revealing if the username / email was correct you are making it more difficult for a malicious user to gain unauthorized access to the platform.

Impressive stuff! We are looking into solutions that will allow us more real-time access into SIMS, but there is nothing concrete yet to report. I mentioned the lack of address information in Frog to our MIS guru, and made them aware that this could be useful for people going forwards. I believe (don't hold me to this) that the reason we don't currently have that information in Frog is mainly down to GDPR - as you are only supposed to hold information on your system that you need - and not keep stuff that you don't use. Glad to see you've got a nice solution working for you

Hey folks! Just a quick reminder about posting on the forums as related to GDPR. As you know we all have a responsibility to ensure that personal information is handled correctly. Since this is a public forum, you are reminded that when posting images that may contain such information, to ensure that anything personal (names. usernames, addresses etc....) is blanked out. Also take care when posting code snippets etc... If we spot anything on the forums that might be a problem we'll remove it and ask you to re-upload a sanitized version. If you need to send more detailed information then it can be done via our support system - that way everything stays nice and private. Thanks everyone

Great SCOTT!

You could try importing some new users with the SEN field. Probably with a Value of Y - which might make the test students appear in that list. Worth a try anyway.

I'm on annual leave this week, and don't have access to the code, so I can't check it for you. I will have to refer you to @Graham Quince for now!

Next time I have a performance review, I'll be sure to point out this thread ?? The other things are going to take more thinking!

Right, honest answer - at the moment, I don't know! It could be that the upload button press is performing some default html form-like action, which may be trying to submit the form. I'd need to see the code for the upload button. However, you could try changing the above bit of code to this: obj.modal.find("[data-name=file-upload]").click(function(el) { el.preventDefault(); Disclaimer - this is a wild-stab-in-the-dark-with-no-research-whatsoever-type-guess.

I assume that worked then? ?

Try this perhaps? obj.modal.find("[data-name=file-upload]").click(function() { $('.os_core:first').trigger('os.app.upload', { "data": { "upload_type": "asset", "site_uuid": "62D4442D2002520CF7345F0960EDDD095847DB4C186723A6", "focusApp": $('.modal'), "callback": function(result) { if (result.files && result.files.length) { $.each(result.files, function(i, file) { console.log(file.attachment.name); }); } }, launchAboveModal: true } }); notice the: launchAboveModal: true param. It looks like we use that param in a few places, so I'm hoping it does what you need it to do.

Hmmm, is this a custom modal, or using our built in modal? If it's our built-in one then it should work. If not, you could convert it to using our bsmodal stuff maybe? I don't have the exact syntax on hand at the moment, but when I get a chance I'll drop something here.

There are tonnes of them. Pretty much everything in Frog is either a component or a module (at least, we always try to do that). Unfortunately they were for internal use, so we don't have any documentation as such. All of the things you mentioned have either a component or a module associated with them (for easy reuse and consistency throughout the platform). However, we shall need to call upon the front-end guru's of Frog in order to unlock this mystical power. To get started though, I can see that we have: frogui_components_date_time_picker //date time picker frogui_components_curriculumbrowser_subject //subject picker (I think) frogui._modules_selectusers //users select A quick check shows we have around ~60 modules and 100 components - so if you're trying to do anything in particular, it might be worth asking if we have a component available for it first (pretty much if you can see some functionality in the front end, there's a good chance we have something already)

Right, Sorry about the delay in responding, super busy here at the moment (as always!). You could try something like this: FrogOS.openSite({ site: datalink, assignment_uuid: uuid, fullscreen: false, resizable: true, height: 500, width: 500 }); I've not tested this - but the code seems to look like it will accept those params. If not, I'll have to consult one of the front-end experts. Obviously you don't need to pass any params you're not using - for example assignment_uuid

Sneaky preview of FrogDrive with an installed package. Quick note, that I've noticed that some older SCORM packages tend to use a lot of flash. These are going to have problems running, due to browsers dropping support for Flash entirely. https://www.chromium.org/flash-roadmap#TOC-Flash-Disabled-by-Default-Target:-Chrome-76---July-2019-

I reckon this will make me cry. Obviously ePortfolio's work differently from your example above. That's not to say that it's impossible, but it's certainly more than a quick ten minute job to do this. @Matt

What API request are you making and which parameters are you sending?

I haven't checked, but I assume pressing that button fires off an api call to clear the poll, in which case a html widget with a bit of javascript could do the trick?

I should go on holiday more often ? I quickly scanned the thread, so I am kinda up to speed - the issue was that you were trying to save something to the datastore that was using the uuid of a child for one of the parents - and it wouldn't let you, correct? In that case, I will speak to @simon brahan about this, because we do have helpers that allow us to easily check if a parent has permission to see data related to a child (e.g. they need parental responsibility over that child etc). I'm pretty sure that the helper also checks the court order flags from your MIS systems as well. It may be worth investigating how easy it would be to alter the FDP endpoint to do this check on a passed user. I suspect it would be trivial. Something to think about at least.

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.

You could try opening the site and at the top: Site -> Site assets, this should load a window with all the site assets. This may have the photostream images in them and you might be able to delete them from here? Might be worth a try.

I'll be passing the site_uuid to the data-store, all you'd need to do is pass the page_uuid instead. We can have a play sometime and see if we can get it working.

I honestly can't remember. If I get a moment I will look at the code, but I think that it records page visits. More specifically, I think it uses the widget id as the source. So if you put two on a page, they might show different data.... I'll have to look into it. You could test this by putting this widget on each page of a test site and visiting it a few times to see what data it shows.

Just FYI - I think we've found the problem causing the slowdown and so hope to have this fixed and available to you as soon as we can.