> Can you add the screenshots to the bugzilla? Good place to reference them > later.
Will do. > You have In Progress and All. Part of me thinks you'd need a Completed one. Ya know, I actually thought about that too, and it's so simple I'll throw it in so we can see how it looks. > What if something Fails? what then? That's tricky. I wanted to do some sort of "failed" state, but when would it be failed? If one or more of the servers in the set for the operation fails? That part wouldn't be too bad for server-side operations (change channels, delete server). I could enhance the operation->server mapping table to carry some lightweight information on success/failure and display the failures more prominently in the details page. But client-side operations get trickier. There are a few options: - Add something into the event handling code to know its part of an SSM operation and update the success/failure field as described above. That would let us treat server-side and client-side operations the same as far as this log is concerned, at the expense of adding the ugliness to the event handling code (not a fan of this approach) - Add a distinction to the SSM operation data to know if its a client or server side operation. Based on that, we either query the success/failure info as above (server-side) or query the event history for the server to see if it completed yet (client-side actions). The latter may not be 100% correct. I may be wrong in my assumption that the event history is only stored for client-side actions. When porting the channel subscription change I know there was a place to snap out a log entry; I'm still waiting for my IDE to load to check into it more closely. > Also, if you want to create a page for > each state, you could use the same page with a formvar of state= that can be > used to filter it. I tried that first, but I was running into issues with the rhn-tabs. I originally had: /ssm/ViewLog.do?mode=all /ssm/ViewLog.do?mode=inprogress But when I did that, the subtabs didn't properly reflect which page you were on. I kinda assumed the subtab code didn't look at parameters for uniqueness and just thought both of those URLs should match /ssm/ViewLog.do and thus went to the same subtab. I also tried one action, multiple struts mappings for it, passing in a parameter to the mapping in the struts-config.xml to dictate what it should show, but I couldn't remember how to actually get that parameter back out in the action itself :) So in the interest of getting the UI done for discussion, I subclassed the base action with very thin subclasses that indicate what to show and the message key for the summary field. I'm open to the parameterized, single action approach if someone can kick me in the right direction on why my subtabs were misbehaving. > I noticed the url of the first 2 screens have no formvars. How does one get to > these pages? Is it triggered by user? serverid? or something else? Not completely sure I follow the question, but I think the answer is that these are all operations triggered by the user. Since we never snap out a label for the SSM at a point in time, there's not really a finer-grained view on the data saying "show me the log for 'jdob's bad ass set of servers'". It's just "What has jdob done in the SSM." > On the last screenshot it shows progress, will that progress update while > the user is looking at the page? What about the progress in the lists? Not > sure > we have progress in a list before. It's something I'm trying out and not wed to. The idea was since we're dealing with a set of servers, it felt like we should be able to reasonably say how many of them have been processed and how many remain. I wanted a way to show the user that it's actually doing something, not just sitting there perpetually in progress. In reality, I don't think it's gonna work. Again we'd have to do some weirdness to update this for client-side actions so we know when they complete. For server-side, my first use case already broke down. When I optimized the channel subscription, things are done against servers in RhnSets. So while I could potentially update the progress to track the population of these sets, even when that's finished we're not 100% done as we still have to do the subscription changes, which at that point is done in bulk in the DB and I'll only know when we begin them and end them all. > Overall I like it. Nice job. Thx. :) > Nope the link is fine :) that's kinda how we do it everywhere else. Good to know, thanks. > jesus > > _______________________________________________ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel -- Jason Dobies (jason.dob...@redhat.com) RHN Satellite & Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk, #spacewalk-devel _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
