As a possible temporary workaround I added a custom stylesheet to my Safari. Within my custom style sheet I did the same like in the PR: .ibo-navigation-menu.ibo-is-active .ibo-navigation-menu--drawer{ -webkit-transform: translate3d(0,0,0); }
See also this PR https://github.com/Combodo/iTop/pull/340
As far as I am able to see you are using a Trigger with the target class "Ticket" and the log attribut "public_log". Using the default datamodel the attribut "public_log" does not exist for the class Ticket. It is only defiened within the sub classes "Incident" and "UserRequest".. I am wondering that your solution seems to work with previous iTop versions..
I wasn't aware of this fact as well, so thanks for ponting that out Eduardo. iTop version and those meta information for are no personal information. But I absolutly agree with Hipska: Best practice would be at least inform users about that fact. When thinking about private custom modules, like Thomas wrote: I could imagine not everybody would like to share which custom modules he has installed. Esspacially if he is not aware of the fact, that those information are transfered to Combodo.
Hi there, wish you all the best for 2022! Basically I agree with Jeffery. When defining log entries as objects in the datamodel, it become a lot more easier to extend. Additional to those benefits which was already mentioned I am thinking for instance about more context information of incoming mails: Let's imagine we've got a class called "CaseLogEntry" which got attributes like "content (HTML)", "linked object", "timestamp", ... It would be possible to extend and create a sub class "CaseLogEntryFromMail"...
Hey Yann, If you need professional help with iTop you should contact combodo directly or find a combodo partner who is able to help you. Have a look here: https://www.combodo.com/find-a-partner
Hey Yann, you are right approval process automation is build for UserRequests not for Changes. To implement something similar for Change Management you have to create your own extension which implements a new class derived from the abstract class "ApprovalScheme" and implement the methods of the abstract class. It's a little piece of work :-) Not sure whether there is currently already an extension in the community available, which have already implemented it.
Sounds like the module php-zip is not installed. But this should have been mentioned in the prerequisites at the beginning of the setup. Could you check whether php-zip is installed and enabled?
The idea of changing the way of how log entries are stored (and split then up into multiple database records) sounds pretty interesting to me. Especially compared to CMDBChangeOp objects log entries are stored pretty "flat" currently. I could image, a new way of storing those entries could offer a lot of opportunities in the future. Thumbs up from my site :-)