7.2.7 Lab Answers
Qiana Thieklin
I would like to upgrade the FTD equipment on my campus to release 7.4.1 (latest available), but I can't understand if it is reliable or not. Cisco continues to recommend release 7.2.5 (which has serious security bugs anyway). Version 7.4.1 was released in December 2023. How is it possible that it is still not considered reliable? Has anyone had experience with this version? Is it safe to put it on production equipment? The alternative is version 7.2.7 which came out in 29 Apr 2024.
The suggested release gold star is based only in part on reliability. Another consideration is how many users are running it in production, as ascertained by Cisco telemetry. If everybody holds off waiting to see the Gold Star, it will never get there - literally. I personally have several customers running 7.4.1.1 on their production FMCs and FTD with no problems at all.
I think I found why your system is saying it is up to date. Go to System>>Fortiguard and see if the Firmware & General Updates is Expired. If yes the message you are up to date will show up for version. If it is not expired then a message need to update will be thre.
hello earthlab
you can get the 7.2.7 upgrade file from support.fortinet.com downloads 7.0>7.2.7 > then find your model device then click HTTP link to download
Once you have file you can click link browse for file and update that way.
Also trying to update a 60F to 7.2.7. Under System/Fabric Management, I see "Upgrade to 7.2.7 shortly" under the Upgrade Status column to the right of the firewall. I don't see the System/Firmware page in the left nav as it shows via the link: -Tip-How-to-manually-download-Firmware-of-Forti...
I read that FortiGate firewalls lower than 100 series have automatic upgrades enabled. Is there a way to temporarily disable the automatic update to resolve this security vulnerability? I tried the following but I'm not sure that this worked, and I don't see access to manually update the firmware via the GUI:
Also trying to update a 60F to 7.2.7. Under System/Fabric Management, I see "Upgrade to 7.2.7 shortly" under the Upgrade Status column to the right of the firewall. I don't see the System/Firmware page in the left nav as it shows via the link above titled: How-to-manually-download-Firmware-of-FortiGate
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
A few weeks ago, I wrote a post titled, So Mediocre They Can't Ignore Me. In that post, I talked about trying to make-up for my lack of design talent with my ability to focus and grind things out. And today, that's what I'm trying to do. I have a rough idea for a feature I'd like to add to InVision. As such, I'm seeking feedback from you all on my idea. The hope being that I can use that feedback to both improve the idea; and, to demonstrate that the idea might have some traction when I pitch it to our Product Team.
I'm calling the feature "Screen Flow", though I'm not married to that name. Screen Flow is essentially an alternative view into your Prototype that attempts to automatically arrange the screens in a hierarchical map based on the embedded hotspots. You can think of it as being akin to the old "Site Map" concept in the Web 1.0 days:
While this sounds like a simple idea, there are a number of complexities that I don't have great answers for. The most obvious being that the screens in a Prototype are highly cross-linked. Meaning, a Prototype is more akin to a spider's web than it is a clean, hierarchical flow of links. Of course, rendering the Prototype flow like a spider's web would make it completely unusable.
My current solution to this problem is to render the Screen Flow as a directed acyclic graph. Which means that I start at the first screen and then traverse the hotspot links, making sure to never revisit an existing screen:
Of course, I don't want to lose the utility of the cross-linking, so when you hover over a screen, I attempt to highlight the linked screens, even if those screens have been previously visited - notice the blue-borders and shadow in the following screen-shot:
Then, there's the matter of hotspots that don't represent deterministic screen-to-screen links. For example, InVision allows you to create hotspots that "go to the next screen" or "return to the previously-visited screen" or "show as overlay". While some of these hotspots can be made deterministic at compile time, the "previously-visited" screen concept is a dynamic, runtime concern that can't be mapped to a static value.
And, of course, it's unclear as to whether or not this feature would actually provide any value to the user. My gut says Yes - at least something. But, I'm also too emotionally involved at this point to be objective. That said, I appreciate that the Screen Flow provides the user with an alternative, topographical view of the Prototype. And, that is sheds on light on screens that may not be reachable based on the current hotspot configuration:
So, that's the idea that I have so far. I'd really appreciate any feedback both positive and constructive. This way, I can polish the concept and get it to a point where I feel it's ready to pitch to the Product Team at InVision.
You say you're not a designer, but this is a very clean interface with a good layout. I didn't know what InVision is so I had to read up on that before I understood why you created this demo. It seems like a logical and natural feature to add to InVision.
One of the first gen HTML design tools would build a flow chart so you can visualise all navigational journeys that users can take, and it flagged up pages that nothing linked to as well as links that went somewhere that didn't exist. Am I thinking of HoTMetaL or Frontpage?
Thank you for the kind words -- this is like my 5th attempts at designing this, with some good feedback from my local team's Project Manager. The first pass was much heavier and had more UI elements that didn't really need to be there.
1. This is a very useful feature.
In my work as a UX designer, I regularly, manually, create flow diagrams. "Screen Flow" would drastically reduce my efforts! Additionally, it would be a handy visual for a variety of stakeholders, from developers looking to get a sense of the app to clients seeing how different features connect together.
2. I think the "spider-web" concern could lead to a great feature.
You mentioned how one screen linking to many could lead to a "spider-web" map, and I think this could be viewed as a positive! I love the idea of using Screen Flow to create custom flow diagrams for different task flows. For example: you could select a screen, select one screen from the many it links to, and then continue onwards to create and save a particular flow through the system. This would be invaluable for mapping different flows through a large, complex app. Perhaps you could call this, "Screen Flow: Choose Your Own Adventure". ;)
3. This would make a terrific view on InVision Cloud.
I love the idea of Screen Flow as an alternative view on InVision Cloud. From the default view, I could toggle to a Screen Flow view, and then maybe have custom-defined flows within that view.
Ben. This reminds me of the Apple XCode StoryBoard tool. I used to develop iOS Apps and the StoryBoard tool, allows one to move, shorten, lengthen and change the angle of each interconnecting line, to make the most of the screen real estate. As the lines get closer to a hot spot, the magnetic effect increases and tries to attract the line to a docking point. Essentially, this allows connecting lines & hotspots to become interchangeable. And, ultimately allows one to find the perfect balance between empty space and a compact flow, which becomes more important in larger projects.
Sometimes, in big projects, it can be a little disconcerting, if one has scroll downwards endlessly, because it is easy to forget what the previous flow looked like. So, as one scrolls down, maybe the hotspots & lines above could auto compact, using some kind of algorithm. Let's face it, we only tend to concentrate on the central part of the screen. As one scrolls back up the lines & hotspots gradually unpack again. But, maybe this is way to ambitious, although I am not exactly sure how many resources, you would have at your disposal, in terms of manpower & technology.
For example, does invision have components that contain links centrally? The problem statement might be, a user changes their nav and has to link pages many many times...link each nav item for each page. If it was centralized, they could do it once instead of many times. This is a problem with Adobe XD actually, but really easy in Figma.
Second thing, organizing screens is a difficult problem because there is such variety in flow. Complex business apps have a lot of intricate cross navigation. It's not like a website with simple global and local. Your solution might optimize for one scenario but not another.
So ask yourself, "what is the problem? Who has this problem? How often does it come up? How annoying is it? What are the three ways I could solve the problem? How hard are those solutions to implement?"
Really good points / questions. Especially about how different "Web sites" and "apps" are. In fact, that very diverge in linking complexity is part of why it has taken me so long to even wrap my head around this possible UI. It wasn't until I realized that "I didn't have to show EVERY link" that I even had some approach that made sense. Essentially, I'm somewhat dumbing down_ the complexity of an "app" so that it can be rendered more like a "web site."
93ddb68554