Hello @sneha_surve,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno learning path is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Drupal 11 compatibility will be included in the next Opigno LMS release and will be done by Opigno team.
Hello @sneha_surve,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno dashboard is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Thank you for reporting this issue. It has already been resolved in OpignoLMS 3.2.7, which is now available for download. I am marking this issue as resolved.
Hello @manishvaity,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno SCORM is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Hello @manishvaity,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno Tincan API is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Hello @manishvaity,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno Forum is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Hello @manishvaity,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno dashboard is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Hello @manishvaity,
Thank you for your offer. We appreciate it, but at the moment, we are not open to co-maintaining the Opigno project. Since the Opigno dashboard is part of the Opigno LMS, which is maintained by Connect-i, we are unable to agree to co-maintaining its dependencies.
Additionally, the disable_reset_password checkbox in the AccountSettingsForm states that it removes access to password reset page for anonymous users only. However, the DisableResetPassword access check currently only verifies the disable_reset_password option. It seems this should be addressed as well.
Hello. The UserLoginForm.php displays the Forgot your password? link when an unrecognized username or password is entered. We need to hide this link if the disable_reset_password option is enabled.
The fix has already been included in version 3.1.1, so I'm closing this issue. Thanks, everyone, for your work on it.
I have created MR and added a patch. Please review.
id.aleks → created an issue.
Hello @Graber,
Thank you for reporting this issue. It is better to limit the addition of these forms to the pages where they are used, instead of removing them completely. Otherwise, it will break the login functionality of Opigno. I have created MR and attaching the patch. Please test and review.
id.aleks → made their first commit to this issue’s fork.
id.aleks → created an issue.
Hello @catch, thank you for checking this. I agree with your opinion. I have pushed new changes to the MR and also added a new patch to this comment. Please review.
I have opened the MR https://git.drupalcode.org/project/h5p/-/merge_requests/18. Also attaching the fix as a patch. Please review.
id.aleks → created an issue.
Hello @drunkey_monkey,
Thank you once again for your contribution. The rephrased error message is now much clearer. From an end-user's perspective, it's more understandable what is occurring. All tests are passing, so it looks good to me. I'm marking this issue as RTBC!
Hello @drunken monkey,
Thank you for your work on this issue. Indeed, the situation has improved significantly with the patch. The wording of the message is clear, and the locking system has definitely resolved my issue. While I agree that the patch might not fix all possible cases, it's better than having no solution at all. The scenarios you mentioned are less common compared to this specific one, so I'm satisfied with this patch.
I do have one note regarding an improvement: When a SearchApiException is produced due to an available lock, the exception message is "Items are being indexed in a different process." However, in the IndexStatusForm::submitForm, the system catches this exception and only displays a warning message: "Failed to create a batch, please check the batch size and limit." I suggest aligning the warning message with the exception message for clearer communication to the users about what is happening.
Here is my test result:
+
Adding a patch from MR in case someone needs it.
I have created MR. Also adding a patch.
id.aleks → created an issue.
id.aleks → created an issue.