AnonymousJanuary 24, 2018 at 4:57 pmPost count: 16
Hi Team, I’ve uploaded staff into our portal but when I give someone directory administrator permission they cannot click on anyone’s data unless they have super admin permissions. When I look at the code, it appears it should work. Thoughts as to why it isn’t working? I also would like to leverage a like operator but since it is encrypted, that throws a little hitch in doing so. Do you have plans to use wildcards so someone doesn’t need to know the exact name to get a result? I’m a bit hesitant to modify your core code since updates will likely overwrite, correct?
Zach Vander VeenKeymasterJanuary 24, 2018 at 7:08 pmPost count: 9
The Directory App actually has 4 roles:
- Default (which isn’t actually a named role). This basically only shows the table for staff with name, email, location, and role.
- Directory Adviser: Can view more details of the individual like phone number, address, etc. But not confidential info like SS or discipline records
- Directory Supervisor: Can view all the fields. But CANNOT delete folk. When they “delete” they’re basically archiving them
- Super Admin: Full permission with capabilities to delete actual people
You can assign roles by searching for the individual (assuming you’re the super admin), click on their name, then search for the field (it’s near the bottom). (See rolelist.php file).
At Hamilton, we’ve it set up like this:
- HR and HR Secretaries have Supervisor Role
- Various folk have Adviser roles (ie Superintendent, etc)
- I have super admin
- Everyone else has the default role
Using a like/wildcard operators is on the roadmap (I want it too), but not developed yet. We don’t really need to encrypt the entire table, just certain key fields.
As for modifying the code. Please do. Then contribute back to the community so we can merge it!
Hope that helps!
Brandon WilsonParticipantJanuary 25, 2018 at 9:15 amPost count: 17
I think Zach covered a lot of the questions in your message. I just wanted to touch on your last question. You are able to modify the code, but when we push a new core release, and you update your version, our code will overwrite any files you have changed. The best way to get your changes implemented permanently is to contribute back to the open source code. You are able to do this through Github. If you are unfamiliar with Github, I would be more then willing to meet with you and walk through how to post your changes. We are also adding documentation for the contribution process to our website soon!
Let me know if there is anything I can do to help!
Brandon WilsonParticipantJanuary 31, 2018 at 11:32 amPost count: 17
I wanted to let you know that we are in the process of adding an update to decrypt certain values of the directory. This should improve the search-ability of the directory. These changes will be released in 4.3.2 of Abre.
There is an important note here: Once 4.3.2 is released and you update your Abre installation, you will need to re-import your directory OR write a script to convert the currently encrypted values to non-encrypted values for all entries in your database. If this isn’t done, things will break.
I wanted to make you aware of these changes as I know these will impact your installation. Let me know if you have any questions!
You must be logged in to reply to this topic.