Hi,
Since appraisals are assigned to the manager at the moment of activation, and don't get reassigned when the manager changes (something which I really hope is going to be fixed in 2.6), would it be possible for the Appraisal Status report source to reflect which manager the appraisal is assigned to as well as who the user's manager currently is.
Thanks
Dan
Hi Dan,
I can see how having both columns would be vital for finding the appraisals where the user's current manager is not the manager assigned to their appraisal, I'll file an enhancement request.
Thanks for that, would be really helpful. This said, could I also have some confirmation as to whether the issue of appraisals not following a member of staff when they are assigned a new manager will definitely be resolved in 2.6. This is currently causing us significant problems, and without that assurance I am currently having to strongly suggest to other organisations who might be thinking about Totara for their learning and appraisal needs that they should look at alternative solutions when they ask me. I am aware that we're one of the first organisations of our size and complexity to actually launch the appraisal functionality, but there are other organisations I'm aware of that will very soon be discussing the possibility of moving to Totara.
Dan
Would it be possible to add the new manager into the user's Appraiser or Temporary manager position so the new manager would be able to approve the appraisal stage.
It looks like the Appraiser is a field in Totara sync but not temporary manager so could possibly be synched to Appraiser position.
Craig
Hi Dan and Craig.
Simon thought it would be a good idea for me to reply to your questions since I've already made a couple of posts about it and I've done a lot of thinking about how this works. I'll start by linking to the previous discussions relating to this:
The first link explains why temporary managers can't help solve the problems that you're looking at.
The first paragraph in my reply in the second link contains some of the questions that need to be considered before a solution can be implemented. It would help us if you (and anyone else reading this) could give us some ideas of how you would expect Totara to handle these situations:
As I said in an earlier post, I've already got some code to detect when these changes occur, but deciding how to handle them is a complicated problem. Should these settings be site wide or appraisal specific? Can they be changed during the appraisal? Are they automatic or should a manager/administrator be able to manually determine the reaction to perform (similar to exceptions in programs)? Different people will have different requirements, so we need to come up with a solution that will be as flexible and consistent as possible.
It's not going to be possible to add this feature to Totara 2.6 (our feature freeze is about two weeks away), but we (and I specifically) really want to get it in to 2.7. It still requires some thinking, so hopefully your feedback on these ideas will help us. Even better, if a Totara partner or client was willing to fund or implement this feature then I'd be happy to give the code I've already developed and I'd help as much as possible to work out the requirements/specification and to get it integrated into Totara.
Nathan
Thanks for the details on this
It would be good to have the temporary manger to be applied for the position and role so the temporary manager is able to do everything a manager can do.
The model for how appraisals work doesn't seem to quite match up with some of your expectations.
Currently an "appraisal" is an object that contains all the details about the process, e.g. questions, stages and stage dates, permissions etc. Each row on the "manage appraisals" page is a single appraisal. It is expected that there would be one "appraisal" with groups of users who need to do that appraisal assigned to it.
When you say "would it be possible to automatically copy appraisals for new group members and give the opportunity to edit the dates, stages" while it is technically possible it would mean creating a duplicate of the whole appraisal object every time a few new users joined a group that was assigned. That would quickly become a headache to manage - the manage appraisals page would fill with duplicate appraisals and if you wanted to change something you'd have to do it in multiple places.
What should happen if the added user is missing a required role (e.g. no Appraiser, where Appraiser is required to complete the appraisal)?
a warning saying user is missing role and the users appraisal not created as the appraisal won't be able to be completed
The problem is that a user being added to a group can occur on the cron, or via another method that doesn't give us an opportunity to post a warning to an admin. You could have a situation where an audience is assigned to an appraisal, and a user who doesn't have an appraiser sets a user profile field that causes them to be added to the appraisal.
Whatever system we implement we need to be able to defer these decisions until a later time. This is why we are thinking we need "exceptions" like in programs.
Simon
Modelling appraisals on the programs module for exceptions and event based assignment would be useful as it
Definitely agree with Craig, if appraisals functioned in the same way that programs did, a lot of the issues people are having might not occur. Currently, because reassigning a user to a new manager doesn't move the appraisal, we are having to create copies of the appraisal we've pushed out to everyone and assign all of the users we've moved to this new copy. The users then need to wait until we push out the new appraisal before they can start with the new manager, which either means hundreds of copies of the appraisal (as described above) or using having to wait so we can "batch" them into reasonable numbers. We are currently working with our Totara partner to get some custom code written which will allow the appraisal to follow the user when they are reassigned, and we will definitely look at contributing this back to Totara Core if they want it because I suspect a lot of people would benefit.
Dan
We have had some more discussion around this, and while exceptions seem like the obvious solution they do add in quite a bit of extra complexity due to some subtle differences from programs. In fact the more we think about the details the more complex the solution becomes.
We took a step back and considered if there was a more straightforward solution that would solve 90% of the issues you are having in a more straightforward manner (that would be quicker and easier to implement).
Your thoughts on the proposal below would be appreciated:
That sounds like an excellent solution, and would solve all of the problems that we have I think. The only thing I have to ask now is when would this change happen, and how sure are you of that answer?
Thanks
Dan
We've done some scoping and estimates of the feature as proposed and we estimate it is about 23 developer days work (see below).
We won't have any core developers available now until after the 2.6 release cycle. We can prioritise this as our first 2.7 enhancement but it would still take until mid-June before it would be done (based on the estimates below).
Alternatively we could commission a Totara partner's development team to complete the work sooner, but that would be dependent on funding and also developer availability within our partner network.
Integration into a stable release definitely won't happen until 2.7 now but if developed sooner you could apply a patch knowing it will definitely be in 2.7 (so any customisation would be temporary).
Appraisal work estimate
That's brilliant, and it really is appreciated you prioritising this as the first enhancement of the 2.7 development cycle. We will have our Totara Partner liaise with you about the code and getting a copy in June once it's hopefully done so that we can run it (and provide feedback) before 2.7 comes out.
The above looks excellent, and covers everything we wanted and more. The only slight thing (and this really is small) would be a tweak to the navigation of stages in an appraisal. Currently, if a stage has been completed, there is no way to navigate directly to the start of that stage from the main appraisal screen. To access that stage, you need to go into the current stage and navigate back using the tabs on the left hand side. Would it be possible for there to be some way to directly navigate to the start of each completed stage directly? As an example, our first stage is setting objectives and our second stage is keeping notes of ongoing meetings. Users are confused by the fact that, once they have set the objectives and completed that stage, they can't just click on something (the title maybe) in stage 1 to directly view the objectives again.
Hope that makes sense, thanks again for giving this some priority
Dan
Hi Dan.
That's a good idea about the buttons to take you to the start of completed stages. I don't think it would be difficult. But it will have to be in a patch of its own.
I was going to say that it would have to wait until 2.7 (or I could send you a patch) since it's a feature, but then I wrote the whole patch when I was half way through writing this message and Simon said it's ok to include in 2.6, so it's in review already.
Nathan
That's brilliant, thanks for that. It's only a small tweak, but it did seem to confuse a lot of our users!
Regards
Dan
Just wanted to give an update - we have a patch prepared and just need to write some automated tests, put it through code review and testing. I would expect that we will have something ready by the end of June if not before.
Once the patch is merged in we will put together a patch for 2.6 that people can apply if they want to use it before 2.7.
Simon
It's disappointing that this has been delayed to 2.7, particularly given that in the links you posted there was definitely mention of it being aimed at 2.6. I'm guessing this would be a big feature for you to consider contributions from a partner being included in a 2.6 point release, so it would have to be 2.7.
I can also imagine that this will make it a little tricky for partners to sell Totara as including an appraisal functionality, because as soon as a customer starts to test the system they will try things like changing manager and discover it doesn't work, but it may well be that organisations are not particularly looking at the appraisal functionality currently.
To answer the questions (in broadly the order you asked them):
Then an exception report should be generated if a problem occurs, in the same way that adding a user to a group for programmes will. Once the problem is resolved (either exclude the person or they have the required role added to them) then they can safely be added.
This will be down to the organisation to handle. If they have a fixed review period (everyone does it at the same time) then the person should still be added even if the review is brief, or a new appraisal could be created. If the organisation (like ours) has had to create a 3 year long review period for our annual cycle because the Totara Appraisal functionality works with static dates, when it's not a problem.
It might well be useful to produce an exception report for this as well, so that the administrator can make a choice for each user.
If the manager changes, the appraisal has to follow the user (and the previous manager no longer needs to have access to it). I would say manager's manager would also need to change, because otherwise it's not really worth having as a feature. Ideally rather than having the manager's manager role, appraisals should be accessible in a cascading way the whole way down the management hierarchy so that a "more senior managers" role would replace the "manager's manager" one in the appraisal. This would allow anyone up the management structure to perform the actions that "manager's manager" currently can.
100% with Craig on information ownership, the information is owned by the organisation and therefore there are no problems with it passing between managers and no need to restart anything. I would expect a manager to review everything that has been written before completing an appraisal, so that shouldn't be an issue. The one bit of information I would think useful would be who was the manager when a given appraisal was completed, because past appraisals should also follow the user and therefore would need tagging with who was responsible for completing it.
Again, an exception report should be generated, but since the appraisal should be following the user then when they get a new manager that manager will pick up the appraisal. In reality, being without a manager should only be temporary, because ultimately the staff member should be accountable to someone.
Site wide, because if this is flexible enough then it shouldn't be a problem. If it's easier to make it appraisal specific, particularly as a transitional arrangement, then that would be fine but it should be the default for all new appraisals and a "enable for all appraisals" option should be available.
I think, with the exception report approach, it provides the best balance of manual and automatic. If the action will cause no problems (moving from one manager to another) it should be automatic, if there are problems (the user doesn't have a manager but is added to a group) then manual intervention is required.
Sorry if any of that sounded a little harsh, I really do appreciate that this isn't an easy problem to solve and it's good that you are responding to comment, but there is frustration (and a little incredulity) when I explain to colleagues about the limitations of the Appraisal system.
Regards
Dan
Hi Dan,
I am sorry we weren't able to get this done for 2.6, unfortunately the majority of our resources for new feature developments are going towards the launch of Totara Social at the moment, so we have very little resources available for new TotaraLMS features.
You are right that this would not be included in a 2.6 point release given the scope. If it was done as a code contribution though you would of course be able to make use of it before 2.7 but still know that it would be supported by core in 2.7 and beyond.
With regard to the subject of ownership, Nathan was actually talking about who the comments in the appraisal appear to be written by. So if Manager A wrote the comments on stages 1 & 2 and then Manager B took over, because of the way the data is structured the comments would suddenly change and appear to have been written by Manager B, even though they were actually written by Manager A. Clearly that's undesirable, but unfortunately fixing that further adds to the complexity of the task because of the way the data is currently structured.
Thanks for the detailed reply, we'll take that into account when we do get to developing this.
Simon
Hi Joe,
The "deleted user/manager" issue currently has a patch in review/testing and hopefully should be resolved in the next 2.5 release on Tue 10th June
No, just the deleted users for now. As outlined above catering for managers changing mid-appraisal is a pretty big job - work has started on it but it is unlikely to appear before 2.7 in October
Ciaran is right that the changing managers part won't land in core until 2.7 because it is too big for a stable point release. However once we have a fix finished we are happy to make it available for people who would like to try it sooner.
Simon
This fix is now complete, see here for more details:
https://totara.community/mod/forum/discuss.php?d=9563
We still have a bit of work to produce a patch for 2.6 but hopefully it will be ready in a few days. I'll post it here once it's done.
Simon
The patch is in our review system so just needs a bit of testing and it will be ready. Hopefully in the next day or two.
Simon
Attached is a patch of this feature for Totara 2.6.6. To apply this patch you should:
Please note this patch is unsupported as it is not included as part of an official Totara release yet (it will be in 2.7). If you choose to use this patch you will have to manage any conflicts that arise when merging in newer releases or when moving to 2.7 (we will do everything we can to minimise any issues). We recommend you get the upgrade performed by someone experienced in managing Moodle/Totara database upgrades.
If you spot any bugs in the new functionality, please do let us know here.
Simon
We have also investigated the effort in backporting this patch to Totara 2.5. Unfortunately the underlying code changed quite a bit between 2.5 and 2.6. Backporting the patch above leads to a number of conflicts some of which are not straightforward to resolve. We are not comfortable providing a 2.5 patch since there is a risk it could cause problems.
Simon
Hi Simon,
Small thing - but the preview of appraisals doesn't work for us in this patch (no content is displayed after having selected a role).
We know that this one isn't supported, but if you'd have a quick tip about how we could fix this it would be very appreciated as we're working on a PoC with a customer based on this patch.
//Rickard
Rickard, I released a "workaround" for the bug we were getting.
So no worries... we'll wait for the code to be "officially" released.
Fatal error: Call to undefined method appraisal_role_assignment::is_closed() in /mnt/koha/totara/totara/appraisal/lib.php on line 884 Call Stack: 0.0000 639880 1. {main}() /mnt/koha/totara/totara/appraisal/myappraisal.php:0 0.3937 22630840 2. totara_appraisal_renderer->display_pages() /mnt/koha/totara/totara/appraisal/myappraisal.php:273 0.4263 22963272 3. appraisal_page->is_locked() /mnt/koha/totara/totara/appraisal/renderer.php:1712 0.4276 22965816 4. appraisal_stage->is_locked() /mnt/koha/totara/totara/appraisal/lib.php:3097 0.4321 22986208 5. appraisal->is_locked() /mnt/koha/totara/totara/appraisal/lib.php:2266
Best,
Hi Rickard and Larry.
Thanks for bringing this to our attention. It is indeed a bug in the patch and in our 2.7 integration branch. I'm writing a patch to fix the bug and it will definitely be included in the Totara 2.7 release.
Nathan
Hi Rickard and others.
I've made a patch to fix the preview of appraisals when using the 2.6.6 version of the dynamic appraisals patch that Simon posted above. The patch will also be included in 2.7. This isn't thoroughly tested in 2.6.6, but it passed a review for 2.7. If you want to use this patch then make sure you do a database backup before you apply it.
Nathan
Hi Simon
Thanks for providing this.
This worked great until the latest update to 2.6.18. The Totara appraisal code looks to have changed significantly since 2.6.6, and this patch no longer works - on our debugging it raised merge conflicts, errors and failed the unit tests, which led us to compare the codebases to determine the changes made.
We could not find a similar patch for 2.6.18. Is this something your team can provide and if so would you have a rough timeline?
Thanks
Jonny
Hi Jonny.
The 2.6.6 patches were provided as-is and are unsupported. Totara 2.7 has since been released, contains the feature, and is fully supported. We recommend that you upgrade to the latest version of Totara 2.7.
Nathan
