Jump to content

BN_IT_Support

Clients
  • Joined

  • Last visited

Everything posted by BN_IT_Support

  1. Sorry -- please ignore (or delete as appropriate) this bug report. I did not realise that it was an Admin setting to force acknowledgement. Now that I have found it I can see that we should have set it!!! Thanks. John
  2. Hello, Under V4 when a moderator warned a user the user would be forced to acknowledge the warning before they were able to do anything else on the site. This is not being enforced on V5. On V5: Moderator selects to 'warn' user Moderator enters 'note for user' Moderator does not select any restrictions - we don't want to stop the user from accessing the site; just let them know that they have been warned and force them to acknowledge the warning The only funny thing that I can think about for our test site is that it is set in maintenance mode (offline) and users can access the site when offline (this is done so that non-members cannot access the site when we are testing and security might be poor) The user does NOT get any notification so does not know that they have been warned. The user continues to access the site without having to acknowledge the warning (that they don't know about anyway). Thanks. John
  3. Hello, When a moderator is browsing content and decides to hide an item they can click 'hide' from the menu and are then presented with the option to notify the user. The notification works fine EXCEPT that the notification does not automatically link to the content being hidden so the user does not know which bit of their content has been hidden and does not know to which bit of their content the comments apply. When our moderators started testing on V5 they gave feedback on this feature "in the vernacular" (which I am not going to repeat). The gist was that the feature was completely useless without a link to the newly hidden content. A tick box for "add link to content" would be absolutely fabulous - the link (to hidden item) could be added to the top of the edit box. Thanks very much. John
  4. Hello, This is an intermittent problem - I'm sorry that I have not yet managed to work out anything that makes it consistent or repeatable. I'm not the only moderator (on our test system) that has seen this so it does occur maybe 1 in 4 times on our test system??? gallery category set to "require albums" gallery category set to "Images must be approved" user in 'Members' group with no special privileges (not admin, not moderator) If the user submits (for example) 3 images then usually the moderator would have 3 items in the approval queue and would be able to approve them (or not) one at a time. SOMETIMES the moderator only receives one item in the approval queue with no option to approve or not the other two items. Moderator has received 3 emails (one for each item requiring approval) but the issue is that only one of the items has actually appeared in the approval queue Whether the other items (the ones that dodged the queue) are visible or not in the gallery is open to debate! I've just done a test and all items were visible in the gallery and not hidden after I (as moderator) had approved only 1 of the 3. Another moderator has done tests and reports that the queue dodgers were not visible to him as moderator but were visible to the original submitter! Thanks. John
  5. Hello, This change has broken the workflow for our Moderators... The V4 behaviour enabled our moderators to take the appropriate action with "one click" whereas the V5 equivalent would require multiple clicks and is far from obvious. Under V4 our moderators would process the approval queue and mostly approve or delete, BUT, IMPORTANTLY, on occasion it would be necessary to hold the item for further consideration and processing. Skipping the item under these circumstances is not the correct action as one of the other moderators might not realise the problem and might approve or delete. The best way to handle this situation under V4 was to 'hide' the item so it was no longer in the approval queue but had been placed to one side (metaphorically) for later consideration. Thanks. John
  6. Hello, This is a change from V4 (and not a welcome change 😉)... If I create a blog entry I immediately get a banner across the top of the page that says: "Your content will need to be approved by a moderator". This is different from V4 where we just let the members create whatever blogs they wanted (same as we did for the forum topics and posts). If any content was posted that breached community guidelines then the moderators would hide/remove the content and take appropriate action. (If moderators missed the content then someone else would report it in due course - this worked well...) We do not want to have to have our moderators approve all blogs - this would disrupt the free flow of the site. It is entirely possible (although unlikely) that I have overlooked some setting - please provide "appropriate feedback" (!!) is this is the case. Group setting "Can moderate own blog entries?" set to 'off' - it seemed to make no difference and we want it set to off. Group setting "Content: Bypass content moderation?" set to 'off'. Group setting "Content: Require approval before content shows?" set to 'off' Thanks. John
  7. Esther, Thanks - sorry for the duplicate. I could not find my earlier cron bug and as the problem had "gone away" for a time and then "reappeared" I erroneously presumed it was a different bug. Thanks. John
  8. Hello, Most days I get an email showing a cron failure. When I look in the system logs for the time of the email I find an entry: Error: Call to undefined method IPS\core\extensions\core\IpAddresses\Content::pruneIpAddresses() (0) #0 /home/bn2468/public_html/applications/core/tasks/pruneipaddresses.php(51): IPS\Member::pruneAllLoggedIpAddresses() #1 /home/bn2468/public_html/system/Task/Task.php(343): IPS\core\tasks\pruneipaddresses->execute() #2 /home/bn2468/public_html/system/Task/Task.php(306): IPS\Task->run() #3 /home/bn2468/public_html/applications/core/interface/task/task.php(78): IPS\Task->runAndLog() #4 {main} Thanks... John
  9. Hello, [5.0.0] Add Similar Event" fails to set lat/long in event_location and fails to set event_latitude or event_longitude That pretty much defines the problem ;-) Thanks. John
  10. Hello, "Add Similar Event" fails to fire UIItem::formElements (and presumably it does not fire any of the other methods in that extension) Not sure what else to say - it just does not fire it! Thanks. John
  11. Hello, When my application calls Event::retrieveEvents with $skipPermissions=true I get the following Exception: TypeError: IPS\Content\Item::getItemsWithPermission(): Argument #4 ($permissionKey) must be of type string, null given, called in /home/bn2468/public_html/applications/calendar/sources/Event/Event.php on line 2228 (0) #0 /home/bn2468/public_html/applications/calendar/sources/Event/Event.php(2228): IPS\Content\Item::getItemsWithPermission(Array, 'event_start_dat...', NULL, NULL, true, 0, NULL, false, false, false, false, NULL, false, true, true, true, false, NULL) #1 /home/bn2468/public_html/applications/bncal/modules/front/calendars/view.php(575): IPS\calendar\Event::retrieveEvents(Object(IPS\calendar\Date), Object(IPS\calendar\Date), NULL, NULL, true, NULL, NULL, true, NULL, 0, Array) #2 /home/bn2468/public_html/system/Dispatcher/Controller.php(128): IPS\bncal\modules\front\calendars\view->events() #3 /home/bn2468/public_html/applications/bncal/modules/front/calendars/view.php(27): IPS\Dispatcher\Controller->execute() #4 /home/bn2468/public_html/system/Dispatcher/Dispatcher.php(169): IPS\bncal\modules\front\calendars\view->execute() #5 /home/bn2468/public_html/index.php(16): IPS\Dispatcher->run() #6 {main} Note the comment: * @param bool $skipPermissions Skip permission checks (used by REST API to fetch all events which are filtered on later) So I presume the API is also broken (as well as my application). Thanks. John
  12. Hello, I upgraded to 4.7.20 but cannot find the matching SDK. (I know, I know, I should have checked for the SDK before doing the upgrade but it did not cross my mind that it would not be there!) Thanks. John
  13. Hello, I think it probably makes sense to allow more than one SSO handler - for example some users of your platform might have logged into “service-1” and others might have logged into “service-2” and if both services have the potential for SSO login to IPS then you would want two SSO handlers - if the first one succeeds then don’t try the second one (or any other subsequent ones) but if the first one fails then you would want to try the second (and subsequent) in case a later one returns success. It appears to me that the way that Session/Front works it does not get any signal back from the SSO handler to say either “keep on trying” or “we now have success so stop trying any more SSO handlers”. The problems… SSO::onSessionRead() is only called for the first SSO handler in the chain. foreach( Application::allExtensions( 'core', 'SSO', FALSE ) as $ext ) { /* @var SSOAbstract $ext */ if( $ext->isEnabled() ) { return $ext->onSessionRead( $this, $result ); } } SSO::onInit() is called for ALL SSO handlers - so if (for example) the first one is successful Session/Front still continues on down the chain looking for further SSO handlers: foreach( Application::allExtensions( 'core', 'SSO', FALSE ) as $ext ) { /* @var SSOAbstract $ext */ if( $ext->isEnabled() ) { $ext->onSessionInit( $this ); } } Of course, the order of discovery (in the ‘foreach’) is pretty random so the ‘first’ in the description above is pretty random. Even if you were going to make this controllable (sort order) in the future it would be nice to implement the ‘keep on trying’/’all done’ signal now so that my SSO code does not have to be modified in the future ;-) Adding to the above — another problem that I ‘discovered’ just before submitting this… The session data is ‘saved’ BEFORE SSO::onSessionRead() is called and the session data includes details of the logged in member - so, if the SSO module changes the logged in member the session data would be out of date (incorrect). There is no way for the SSO module to update the session data itself as the session data is ‘protected’ and thus only available to variants of Session. /* Set data */ $this->data = array( … Thanks! John
  14. Marc, Would you move the bug report over for me? (Or do I need to re-post in the correct place?) Thanks. John
  15. Hello, As a preamble to this bug report, I’m somewhat confused about where I am supposed to report bugs. The “Beta Discussion” in the IC5 Beta Testing club says “Got a bug? Please post it in our tracker.“ but that takes me to a no-access page. The “New public bug tracker” topic takes me to the “feedback” forum where there appear to be a lot of V4 issues? I’ll try here and see whether it gets moved ;-) I previously reported a bug where Loader::onFinish() does not get called for “database pages”. That is still the case. This report is for additional (possibly related) issues. When using the Page Editor on a simple single column page there are three widget areas - top, middle and bottom. It appears that Loader::onFinish() ONLY gets the content of the “middle” area so that the content of any widgets in the top or bottom areas does NOT get passed to Loader::onFinish(). If that is intended behaviour then it needs to be clearly documented The workaround is relatively simple (for non-database pages) → just drag and drop the widgets into the middle area and test again The next problem is for “database pages”. When a database is created under IC5 a new page is automatically created and the database widget is placed in the middle area. The issue is that the middle area is greyed out in the editor so it is NOT possible to drag and drop any other widgets into the middle area. Thus, the only option for additional widgets is to put them in the top or bottom areas but in those cases they will not appear in Loader::onFinish(). Thanks. John
  16. Hello, This seems more complicated under V5 than under V4 and it feels like there is a bug (or at least a deficiency) here - but I'm not sure so I'm starting this as a discussion rather than a bug report... Under V4 this all seemed to work simply. I could run my test system with IN_DEV enabled and if I created a custom Database Template (e.g. type = Category List - first page when viewing a database) then it would work whether IN_DEV was enabled or not. Under V5 it appears that custom templates created this way only work when IN_DEV is disabled. As soon as IN_DEV is enabled then accessing the database gives a "NO_TEMPLATE" exception because when IN_DEV is enabled under V5 the system expects to find the template files in applications/cms/dev/html/front/databases/etc... and the files are not there. Just the fact that it used to work simply under V4 leads me to feel this is a retrograde step that should be logged as a bug. It is possible to work around the above problem by creating files in the appropriate directory. Of course, most of the file content is a straight copy-and-paste from the template file as viewed in the ACP. But, in addition to that content it is also necessary to insert the line at the top ... something like "<ips:template parameters="$category"/>". What is the expected workflow? The easy way to create templates as the starting point for customisation is in the ACP. But as described above, there is no obvious way to output the templates to files so the workaround is copy and paste with the insertion of he additional header line. The alternative would seem to be to hand-craft the files in the relevant folders and then use the "Import Developer Templates" button to upload all files as templates. That's a nice idea except there is no really easy way to create the starting point! When using the Developer Center to modify one of our applications it is possible to use the Front-End Pages Templates option to select templates to be included with the application. How does that play with the previous comments? Does this option save from the template/dev files or from the information held within Invision tables? Thanks very much. John
  17. While I agree that it would be really great to have the V5 developer documentation "sooner rather than later", you really don't have to wait for the V5 documentation before you start some development. Use the V4 developer documentation PLUS the V5 developer blogs (https://invisioncommunity.com/developers/devblog/). The really big thing is that in V5 it is NOT POSSIBLE to use V4 style 'HOOKS'. If you read the documentation and conclude that you need a V4 HOOK then you are going down the wrong path - read the Dev Blogs and work out how to do it under V5. There are a few useful things that have been added since the V5 Dev Blogs were written and they're not documented yet. But, if you're only just starting to do your development then you're 99% OK if you (1) Use the V4 docs, plus (2) AVOID V4 HOOKS and (3) use the V5 Dev Blogs. Finally, there are people in the forum who will give you pointers if you get stuck on V5 development. John
  18. Well, if you did not delete ALL old DEV files first -- i.e. before copying the latest dev files to your system then I strongly recommend that you check the file dates on all your dev files. (It's a lot easier and quicker to clear out the dev folders first as checking file dates of thousands of files takes time...) You're partly correct that the upgrade of a dev system will go OK. That is, it should be fine as long as you stay OUT of dev mode. If you switch to dev mode and if you did not clear out all the old dev files then there is a strong possibility that some old dev files (CSS and/or JS) will get loaded -- it's just the way that loading CSS and JS works -- it does not load individual CSS or JS files but bundles them so if the old/stale file has a name that matches one of the bundles then it will get picked up and loaded even though you don't want it. When I had stale CSS and JS files in dev mode then pretty much everything worked -- except a few things like some things did not look quite right and I ended up submitting bug reports for things that were just stale files. So, in particular, if you intend to log bug reports I suggest you make sure you don't have stale files hanging around. John
  19. Just a warning for those thinking of upgrading from V4... I suspect that if your system was relatively recently installed (as V4) for the first time then all may well be OK. But, if your system was initially installed as V4 some time around 4th October 2019 or earlier then expect problems... If you can log in then the pages will display as blank. The issue is the following files: applications\core\extensions\core\FrontNavigation\Promoted applications\nexus\extensions\core\FrontNavigation\NetworkStatus applications\nexus\extensions\core\FrontNavigation\Referrals The above files do not exist in V5 but were present in some very old version of V4 (possibly 4.4.7 or older, but I'm not sure). The way the system loads menus is it searches for files in those folders and attempts to load them but as the files have not been converted to V5 then PHP crashes and you end up with blank pages. The 'fix' is to delete the files and your pages will automagically reappear when you refresh your browser. This has previously been reported as a bug - but the answer at that time was that the upgrade would not delete any files. Fair enough - I don't care because I know what to do. If you don't know what to do then expect to trip up 😉 I have a feeling that when I enable IN_DEV mode then I'll run into lots of problems with CSS and JS files being out of date and maybe some others. I think the best advice at this point is to delete ALL dev folders before you install the dev kit John Yes - I can confirm it works (with the warning described above). Download the V5 ZIP Unpack the ZIP Copy the folders over the top of the existing folders Browser /admin/upgrade and log in with your normal adminCP credentials (NOT you invision community credentials) Basically, follow the Installation manual "Manual Install" section. John
  20. Hi Matt, I need an installable kit so I can start converting our many applications and plugins. I guess that probably means that I'll have to wait for beta? But the sooner that I can have an installable kit and start converting plugins and applications the better... Thanks. John
  21. Hi RCITGuy, I can confirm that what Nathan says is the way to do it -- we did the equivalent in August 2023. Short version is (1) you switch PHP to PHP 8.1 which stops your current install from working then (2) you download and install a full kit from your client area on Invision for a manual install. Do ALL the steps in the linked thread and you should be fine. John
  22. Hi, I'm just adding my comment as (1) I was involved in the discussion in another thread and (2) Brian sent me a PM about the issue. As I understand it forums and events are inconsistent with respect to the club setting of "Show Club Content Areas = Only Within Clubs" Take a non-Private club (e.g. an Open club) of which you are NOT a member with the setting as: "Show Club Content Areas = Throughout the Community" https://<sitename>/forums shows all forums including those in the open club - as you would expect https://<sitename>/events shows all calendars including those in the open club - as you would expect Now change the setting to "Show Club Content Areas = Only Within Clubs" https://<sitename>/forums shows all forums EXCEPT those in clubs - as you would expect https://<sitename>/events shows all forums INCLUDING those in clubs - NOT what I and some others would expect If we now play word games we note that under the adminCP setting it states "Content areas are the forums, categories, etc..." so it is explicit that forums will obey the setting but it is not explicit that events/calendars will obey the setting. Does that make it a "bug" or an (unexpected) "feature" 😉 John
  23. If you have a club that you have to join but did not join it then you will not be able to see the events - anywhere. (That is, those events will NOT appear in your normal calendars.) I'm sure that it works correctly in that respect - but in the very unlikely case that it does not work that way then it is a clear bug that needs to be fixed. The issue being discussed was not about events that you don't have permission to see but about events that you do have permission to see (either in an open club or else in a club that you have already joined...). In this case, as you have permission to see the events they will always show up in your normal calendars with no option to control that in the same way as you can control visibility of club forums -- apparently, and according to your test results. John
  24. OK - so looks like you both worked it out -- my suggestion does not help because the "etc." is not explicit one way or the other but your testing shows that events does not behave the same way as forums and is therefore not included in the "etc.". I guess that's a reference to what someone else said earlier? Basically, if you have access to the club then you will see that club's events in your normal calendars (outside of the club). Thus, if you have "open" clubs then all the events from those clubs will be visible to everyone who can access the clubs module (normally every group unless you did something funny like we did). For clubs that you have to join then it will depend upon whether you joined that club... If you did not join then you don't have the permissions to see the events but if you did join then you have the permissions to see the events and they will both show up in the club and also in your out-of-club calendars. Does that match what you're actually seeing? John
  25. There is an adminCP setting (presume it works for events as well as forums) - "Show Club Content Areas" which can be set to one of: "Only Within Clubs" or "Throughout the Community". It sounds as though you have this set to "Throughout the Community"? Under V4 this is a system wide setting rather than per club. John