Re: [foreman-dev] Unify date format in Foreman and plugins
Am 12.04.17 um 18:21 schrieb Ewoud Kohl van Wijngaarden: On Wed, Apr 12, 2017 at 06:02:34PM +0200, Marek Hulán wrote: Thanks guys so far, I'm sending comments below in text that are also relevant for lzap's comments in previous email. On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote: I second that there are cases where "ago" is preferred. For the last puppet run on the host page it's much easier to know if it was an hour ago. Then I don't have to try and remember what day and time it is. However, in a table of all puppet reports then the exact date is the correct unit. The table of reports with a list of "about 1 month ago" has been an annoyance I agree that sometime it's more convenient. On reports page it might be interesting only for reports that arrived withing last few hours though. IMHO the consistency is the key here, I'd like to avoid showing 15 minutes ago for times < few hours and full info for the rest. Most of reports on the page (older than few hours) would benefit from the full format. Therefore I think full format with "ago" information as tooltip might be the best compromise? On the reports (where you see multiple) then I think the "ago" format isn't useful because the granularity is too low so it's hard to compare. IMHO in a list they should all have the same format. On a host page where you see "Last report: 1 hour ago" it does make sense. I hope that clarifies it. I totally agree. Let's not drop the "time ago in words" format entirely. It does make sense in a lot of places, especially reports or certificates or when a host was created. As a user you probably don't care for the exact time. You just want to know approximately when it happened. E.g. when you push new puppet code to your production servers and start to get calls that something is broken, it's enough to know that there are puppet reports that indicate a change happend to your servers within the last hour. As puppet runs happen, when they happen (and the time when puppet applies changes is hard to predict) an exact timestamp isn't useful as your cluster slowly starts to degrade over time. - Timo -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Weekly Design/Dev MeetingL Content Views
https://docs.google.com/document/d/1Oqh0o676iS6ME9gGBPGCs-ToL8yDM882bIJZNNYcfOo/edit Dev/Design Weekly Review - Content Views Presented by Brad Buckingham Create New Version button should be blue. Sync Status should be icon - When blue hover is active you cannot see status List/Remove/Add -- Can these be added together? Will work on some design concepts. Also - second row tabs are usually line style, not box style. (http://www.patternfly.org/pattern-library/widgets/#tabs) Reduce redundancy of always use latest and specific version. Filtering for use latest? Space between tabs… too crowded. Security icon should be red with capitalized S Can Affected Repositories be included into building a filter? Use PF Calendar. (http://www.patternfly.org/pattern-library/forms-and-controls/datepicker/) Success item should have icon If Publish New Version is main item, make blue and break out other items. Otherwise relabel actions with drop down (I believe this is what we are moving forward with in other parts of the UI). “De” and “dev-2” are serif typeface. Change to match other step typefaces This life cycle graphic breaks frequently… I will work on an alternate design. User Help icon for help text on Composite View. Can we use this same “Always Use Latest” drop down on the previous content views -Edit view is the same as previous content view? If there is no data, put statement that there is no content, do not use inline message box. Grey box should be error and appear on checkbox click. Change button to Cancel or Submit - Organization dropdown doesn’t match patternfly - New layout that communicates changes better. This is too generic. - Placement of buttons poor - This wizard doesn’t have steps, introduce new wizard. - Table scrolls which is unusual instead of pagination or longer page scroll - Date is not handled consistently in tables (I know this is being addressed) - Add additional information to bar, lets see the numbers especially on failure. Do we want to keep mimicking dynaflow? Number of column headers and columns do not match. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
On 04/12/2017 09:39 AM, Marek Hulán wrote: <%= l(report.last_report_at, :format => :long) %> which prints "April 10, 2017 17:08". The month name and potentially the format is localized based on current user locale. What is the effort to make this a user driven setting? -- bk -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
On 04/12/2017 11:55 AM, Marek Hulán wrote: On středa 12. dubna 2017 16:14:36 CEST Bryan Kearney wrote: +1 on the format To make sure I am clear: 1) Dates will be stored in the DB as UTC. yes, but should not matter since the TZ info part of the value and we'd always convert it according to current user locale 2) Dates will be shown to the user based on their locale. yes Questions i have: a) If I enter a new date, am I entering it in my time zone? Assume serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12 April, what is stored in the DB? I'm not sure if we enter the time somewhere. AFACT, rex has some time input but I'm not sure how it deals with TZs exactly. I think we should use some time picker in these cases where users would use their TZ and we should convert it to UTC. I am thinking scap runs, katello syncplans are hte biggies. b) What preference/setting controls (2) go to editting form of your profile $username in top right corner -> My account see Timezone field which defaults to "Browser timezone" but can be set to any time zone thanks! -- bk -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
On středa 12. dubna 2017 17:55:21 CEST Marek Hulán wrote: > On středa 12. dubna 2017 16:14:36 CEST Bryan Kearney wrote: > > +1 on the format > > > > To make sure I am clear: > > > > 1) Dates will be stored in the DB as UTC. > > yes, but should not matter since the TZ info part of the value and we'd > always convert it according to current user locale Sorry, just to clarify what I meant. You were correct, DB will store the time info in UTC without TZ info. The input value should contain the TZ info so we can always convert it to UTC. Rubocop warns us when DateTime is used without TZ in mind. If the input is not in UTC, the easiest way to convert it is probably this DateTime.now.utc.to_s(:db) -- Marek > > > 2) Dates will be shown to the user based on their locale. > > yes > > > Questions i have: > > > > a) If I enter a new date, am I entering it in my time zone? Assume > > serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12 > > April, what is stored in the DB? > > I'm not sure if we enter the time somewhere. AFACT, rex has some time input > but I'm not sure how it deals with TZs exactly. I think we should use some > time picker in these cases where users would use their TZ and we should > convert it to UTC. > > > b) What preference/setting controls (2) > > go to editting form of your profile > $username in top right corner -> My account > see Timezone field which defaults to "Browser timezone" but can be set to > any time zone > > -- > Marek > > > -- bk > > > > On 04/12/2017 09:39 AM, Marek Hulán wrote: > > > Hello, > > > > > > I'd like to suggest one recommended way of displaying date/time > > > information on all pages. We started a discussion in a PR [1] that would > > > change the format for config reports, please take a look there for > > > possible solutions. > > > > > > After a discussion with Roxanne (cc) on another page we agreed on > > > following > > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, > > > time is localized in current user timezone. Users can quickly see how > > > long it was before so we didn't display the "x y ago" information. We > > > could add it to tooltip if needed. > > > > > > Once nice thing about this format is that Rails provide helper to > > > generate > > > it. One could use something like > > > > > > <%= l(report.last_report_at, :format => :long) %> > > > > > > which prints "April 10, 2017 17:08". The month name and potentially the > > > format is localized based on current user locale. > > > > > > So before I start sending PRs to various places, I'd like to know if we > > > can > > > all agree on one form, ideally the suggested one, and try to use it > > > where > > > it make sense. Please vote either in here or in the linked PR. > > > > > > The list of various places and formats in Foreman and plugins: > > > > > > * Core * > > > reports page - reported at column: "about 1 month ago" > > > dashboard page: "Generated at 12 Apr 12:41" > > > facts - reported at columns: "about 1 year ago" > > > trends page: "Last updated 1 day ago" > > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > > > hosts - last report column: 2 months ago > > > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 > > > years" > > > > > > * Plugins* > > > discovery - last facts upload: "1 day ago" > > > openscap reports: "about 1 month ago" > > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 > > > 12:49:00 UTC" > > > rex - jobs: "about 19 hours ago" > > > rex - logs: "2017-04-11 19:48:09 +0200" > > > katello - last checking, registered at: "2017-04-12 11:42:06 UTC" > > > katello - content host tasks: 4/12/17 1:42 PM > > > > > > Katello would probably need to implement the rails helper (or whatever > > > format we chose) in their UI helpers. Hopefully that's something easy to > > > do. > > > > > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 > > > > > > Thanks for reading and sorry for the long email > > > > > > -- > > > Marek -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
On Wed, Apr 12, 2017 at 06:02:34PM +0200, Marek Hulán wrote: > Thanks guys so far, I'm sending comments below in text that are also relevant > for lzap's comments in previous email. > > On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote: > > I second that there are cases where "ago" is preferred. For the last > > puppet run on the host page it's much easier to know if it was an hour > > ago. Then I don't have to try and remember what day and time it is. > > However, in a table of all puppet reports then the exact date is the > > correct unit. The table of reports with a list of "about 1 month ago" > > has been an annoyance > > I agree that sometime it's more convenient. On reports page it might be > interesting only for reports that arrived withing last few hours though. IMHO > the consistency is the key here, I'd like to avoid showing 15 minutes ago for > times < few hours and full info for the rest. Most of reports on the page > (older than few hours) would benefit from the full format. Therefore I think > full format with "ago" information as tooltip might be the best compromise? On the reports (where you see multiple) then I think the "ago" format isn't useful because the granularity is too low so it's hard to compare. IMHO in a list they should all have the same format. On a host page where you see "Last report: 1 hour ago" it does make sense. I hope that clarifies it. > > The same goes for the future value, like the puppet ca expiration date. > > Knowing it's in about 4 years is sufficient knowledge. Whether it's in > > May or December isn't that relevent at first sight because I know I > > don't have to worry about it for some time. > > Fair enough, in this case we can keep the format we have. Hopefully noone > starts to replace the certificate when they see "in about 1 hour" :-) T-10, 9, 8 ... :-) > > Regarding the long format I find it much easier to read a table of > > 2017-04-12 rows than April. The length of each record should be constant > > for easy visual comparison. If there is just one value then a > > standardized long format would be preferable. > > Understood. I think the change of month in 30 rows is more visible so you > visually see where one month starts and another begins. Also all April rows > will have the info of same length. But I don't insist, we'll see when we have > opinions from more. That's also a fair point. If you go for the 3 letter versions (Apr vs April) then that could be a good compromise. > -- > Marek > > > > > On Wed, Apr 12, 2017 at 04:18:30PM +0200, Lukas Zapletal wrote: > > > I like "ago" format with hover full date value. Thanks for putting > > > effort in this! > > > > > > LZ > > > > > > On Wed, Apr 12, 2017 at 3:39 PM, Marek Hulán wrote: > > > > Hello, > > > > > > > > I'd like to suggest one recommended way of displaying date/time > > > > information on all pages. We started a discussion in a PR [1] that > > > > would change the format for config reports, please take a look there > > > > for possible solutions. > > > > > > > > After a discussion with Roxanne (cc) on another page we agreed on > > > > following > > > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, > > > > time is localized in current user timezone. Users can quickly see how > > > > long it was before so we didn't display the "x y ago" information. We > > > > could add it to tooltip if needed. > > > > > > > > Once nice thing about this format is that Rails provide helper to > > > > generate it. One could use something like > > > > > > > > <%= l(report.last_report_at, :format => :long) %> > > > > > > > > which prints "April 10, 2017 17:08". The month name and potentially the > > > > format is localized based on current user locale. > > > > > > > > So before I start sending PRs to various places, I'd like to know if we > > > > can > > > > all agree on one form, ideally the suggested one, and try to use it > > > > where it make sense. Please vote either in here or in the linked PR. > > > > > > > > The list of various places and formats in Foreman and plugins: > > > > > > > > * Core * > > > > reports page - reported at column: "about 1 month ago" > > > > dashboard page: "Generated at 12 Apr 12:41" > > > > facts - reported at columns: "about 1 year ago" > > > > trends page: "Last updated 1 day ago" > > > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > > > > hosts - last report column: 2 months ago > > > > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > > > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 > > > > years" > > > > > > > > * Plugins* > > > > discovery - last facts upload: "1 day ago" > > > > openscap reports: "about 1 month ago" > > > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 > > > > 12:49:00 UTC" > > > > rex - jobs: "about 19 hours ago" > > > > rex - logs: "2017-04-11 19:48:09 +0200" > > > > katello - last checking, register
Re: [foreman-dev] Unify date format in Foreman and plugins
Thanks guys so far, I'm sending comments below in text that are also relevant for lzap's comments in previous email. On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote: > I second that there are cases where "ago" is preferred. For the last > puppet run on the host page it's much easier to know if it was an hour > ago. Then I don't have to try and remember what day and time it is. > However, in a table of all puppet reports then the exact date is the > correct unit. The table of reports with a list of "about 1 month ago" > has been an annoyance I agree that sometime it's more convenient. On reports page it might be interesting only for reports that arrived withing last few hours though. IMHO the consistency is the key here, I'd like to avoid showing 15 minutes ago for times < few hours and full info for the rest. Most of reports on the page (older than few hours) would benefit from the full format. Therefore I think full format with "ago" information as tooltip might be the best compromise? > The same goes for the future value, like the puppet ca expiration date. > Knowing it's in about 4 years is sufficient knowledge. Whether it's in > May or December isn't that relevent at first sight because I know I > don't have to worry about it for some time. Fair enough, in this case we can keep the format we have. Hopefully noone starts to replace the certificate when they see "in about 1 hour" :-) > Regarding the long format I find it much easier to read a table of > 2017-04-12 rows than April. The length of each record should be constant > for easy visual comparison. If there is just one value then a > standardized long format would be preferable. Understood. I think the change of month in 30 rows is more visible so you visually see where one month starts and another begins. Also all April rows will have the info of same length. But I don't insist, we'll see when we have opinions from more. -- Marek > > On Wed, Apr 12, 2017 at 04:18:30PM +0200, Lukas Zapletal wrote: > > I like "ago" format with hover full date value. Thanks for putting > > effort in this! > > > > LZ > > > > On Wed, Apr 12, 2017 at 3:39 PM, Marek Hulán wrote: > > > Hello, > > > > > > I'd like to suggest one recommended way of displaying date/time > > > information on all pages. We started a discussion in a PR [1] that > > > would change the format for config reports, please take a look there > > > for possible solutions. > > > > > > After a discussion with Roxanne (cc) on another page we agreed on > > > following > > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, > > > time is localized in current user timezone. Users can quickly see how > > > long it was before so we didn't display the "x y ago" information. We > > > could add it to tooltip if needed. > > > > > > Once nice thing about this format is that Rails provide helper to > > > generate it. One could use something like > > > > > > <%= l(report.last_report_at, :format => :long) %> > > > > > > which prints "April 10, 2017 17:08". The month name and potentially the > > > format is localized based on current user locale. > > > > > > So before I start sending PRs to various places, I'd like to know if we > > > can > > > all agree on one form, ideally the suggested one, and try to use it > > > where it make sense. Please vote either in here or in the linked PR. > > > > > > The list of various places and formats in Foreman and plugins: > > > > > > * Core * > > > reports page - reported at column: "about 1 month ago" > > > dashboard page: "Generated at 12 Apr 12:41" > > > facts - reported at columns: "about 1 year ago" > > > trends page: "Last updated 1 day ago" > > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > > > hosts - last report column: 2 months ago > > > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 > > > years" > > > > > > * Plugins* > > > discovery - last facts upload: "1 day ago" > > > openscap reports: "about 1 month ago" > > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 > > > 12:49:00 UTC" > > > rex - jobs: "about 19 hours ago" > > > rex - logs: "2017-04-11 19:48:09 +0200" > > > katello - last checking, registered at: "2017-04-12 11:42:06 UTC" > > > katello - content host tasks: 4/12/17 1:42 PM > > > > > > Katello would probably need to implement the rails helper (or whatever > > > format we chose) in their UI helpers. Hopefully that's something easy > > > to do. > > > > > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 > > > > > > Thanks for reading and sorry for the long email -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d
Re: [foreman-dev] Unify date format in Foreman and plugins
On středa 12. dubna 2017 16:14:36 CEST Bryan Kearney wrote: > +1 on the format > > To make sure I am clear: > > 1) Dates will be stored in the DB as UTC. yes, but should not matter since the TZ info part of the value and we'd always convert it according to current user locale > 2) Dates will be shown to the user based on their locale. yes > Questions i have: > > a) If I enter a new date, am I entering it in my time zone? Assume > serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12 > April, what is stored in the DB? I'm not sure if we enter the time somewhere. AFACT, rex has some time input but I'm not sure how it deals with TZs exactly. I think we should use some time picker in these cases where users would use their TZ and we should convert it to UTC. > b) What preference/setting controls (2) go to editting form of your profile $username in top right corner -> My account see Timezone field which defaults to "Browser timezone" but can be set to any time zone -- Marek > > -- bk > > On 04/12/2017 09:39 AM, Marek Hulán wrote: > > Hello, > > > > I'd like to suggest one recommended way of displaying date/time > > information on all pages. We started a discussion in a PR [1] that would > > change the format for config reports, please take a look there for > > possible solutions. > > > > After a discussion with Roxanne (cc) on another page we agreed on > > following > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, > > time is localized in current user timezone. Users can quickly see how > > long it was before so we didn't display the "x y ago" information. We > > could add it to tooltip if needed. > > > > Once nice thing about this format is that Rails provide helper to generate > > it. One could use something like > > > > <%= l(report.last_report_at, :format => :long) %> > > > > which prints "April 10, 2017 17:08". The month name and potentially the > > format is localized based on current user locale. > > > > So before I start sending PRs to various places, I'd like to know if we > > can > > all agree on one form, ideally the suggested one, and try to use it where > > it make sense. Please vote either in here or in the linked PR. > > > > The list of various places and formats in Foreman and plugins: > > > > * Core * > > reports page - reported at column: "about 1 month ago" > > dashboard page: "Generated at 12 Apr 12:41" > > facts - reported at columns: "about 1 year ago" > > trends page: "Last updated 1 day ago" > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > > hosts - last report column: 2 months ago > > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years" > > > > * Plugins* > > discovery - last facts upload: "1 day ago" > > openscap reports: "about 1 month ago" > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 > > 12:49:00 UTC" > > rex - jobs: "about 19 hours ago" > > rex - logs: "2017-04-11 19:48:09 +0200" > > katello - last checking, registered at: "2017-04-12 11:42:06 UTC" > > katello - content host tasks: 4/12/17 1:42 PM > > > > Katello would probably need to implement the rails helper (or whatever > > format we chose) in their UI helpers. Hopefully that's something easy to > > do. > > > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 > > > > Thanks for reading and sorry for the long email > > > > -- > > Marek -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Re: Heads up: Use ApplicationRecord base for your models
> Heads up! > > PG::UndefinedTable: ERROR: relation "application_records" does not exist This error appears to show up when Rails devel environment is reloaded on change. We are tracking this down, but be careful until we find this. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
I second that there are cases where "ago" is preferred. For the last puppet run on the host page it's much easier to know if it was an hour ago. Then I don't have to try and remember what day and time it is. However, in a table of all puppet reports then the exact date is the correct unit. The table of reports with a list of "about 1 month ago" has been an annoyance The same goes for the future value, like the puppet ca expiration date. Knowing it's in about 4 years is sufficient knowledge. Whether it's in May or December isn't that relevent at first sight because I know I don't have to worry about it for some time. Regarding the long format I find it much easier to read a table of 2017-04-12 rows than April. The length of each record should be constant for easy visual comparison. If there is just one value then a standardized long format would be preferable. On Wed, Apr 12, 2017 at 04:18:30PM +0200, Lukas Zapletal wrote: > I like "ago" format with hover full date value. Thanks for putting > effort in this! > > LZ > > On Wed, Apr 12, 2017 at 3:39 PM, Marek Hulán wrote: > > Hello, > > > > I'd like to suggest one recommended way of displaying date/time information > > on > > all pages. We started a discussion in a PR [1] that would change the format > > for config reports, please take a look there for possible solutions. > > > > After a discussion with Roxanne (cc) on another page we agreed on following > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, time > > is localized in current user timezone. Users can quickly see how long it was > > before so we didn't display the "x y ago" information. We could add it to > > tooltip if needed. > > > > Once nice thing about this format is that Rails provide helper to generate > > it. > > One could use something like > > > > <%= l(report.last_report_at, :format => :long) %> > > > > which prints "April 10, 2017 17:08". The month name and potentially the > > format > > is localized based on current user locale. > > > > So before I start sending PRs to various places, I'd like to know if we can > > all agree on one form, ideally the suggested one, and try to use it where it > > make sense. Please vote either in here or in the linked PR. > > > > The list of various places and formats in Foreman and plugins: > > > > * Core * > > reports page - reported at column: "about 1 month ago" > > dashboard page: "Generated at 12 Apr 12:41" > > facts - reported at columns: "about 1 year ago" > > trends page: "Last updated 1 day ago" > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > > hosts - last report column: 2 months ago > > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years" > > > > * Plugins* > > discovery - last facts upload: "1 day ago" > > openscap reports: "about 1 month ago" > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 12:49:00 > > UTC" > > rex - jobs: "about 19 hours ago" > > rex - logs: "2017-04-11 19:48:09 +0200" > > katello - last checking, registered at: "2017-04-12 11:42:06 UTC" > > katello - content host tasks: 4/12/17 1:42 PM > > > > Katello would probably need to implement the rails helper (or whatever > > format > > we chose) in their UI helpers. Hopefully that's something easy to do. > > > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 > > > > Thanks for reading and sorry for the long email -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
I like "ago" format with hover full date value. Thanks for putting effort in this! LZ On Wed, Apr 12, 2017 at 3:39 PM, Marek Hulán wrote: > Hello, > > I'd like to suggest one recommended way of displaying date/time information on > all pages. We started a discussion in a PR [1] that would change the format > for config reports, please take a look there for possible solutions. > > After a discussion with Roxanne (cc) on another page we agreed on following > form to be the best "April 10, 2017 17:08". So no timezone, no seconds, time > is localized in current user timezone. Users can quickly see how long it was > before so we didn't display the "x y ago" information. We could add it to > tooltip if needed. > > Once nice thing about this format is that Rails provide helper to generate it. > One could use something like > > <%= l(report.last_report_at, :format => :long) %> > > which prints "April 10, 2017 17:08". The month name and potentially the format > is localized based on current user locale. > > So before I start sending PRs to various places, I'd like to know if we can > all agree on one form, ideally the suggested one, and try to use it where it > make sense. Please vote either in here or in the linked PR. > > The list of various places and formats in Foreman and plugins: > > * Core * > reports page - reported at column: "about 1 month ago" > dashboard page: "Generated at 12 Apr 12:41" > facts - reported at columns: "about 1 year ago" > trends page: "Last updated 1 day ago" > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" > hosts - last report column: 2 months ago > smart proxy - logs - time column: "11. 4. 2017 18:52:31" > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years" > > * Plugins* > discovery - last facts upload: "1 day ago" > openscap reports: "about 1 month ago" > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 12:49:00 > UTC" > rex - jobs: "about 19 hours ago" > rex - logs: "2017-04-11 19:48:09 +0200" > katello - last checking, registered at: "2017-04-12 11:42:06 UTC" > katello - content host tasks: 4/12/17 1:42 PM > > Katello would probably need to implement the rails helper (or whatever format > we chose) in their UI helpers. Hopefully that's something easy to do. > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 > > Thanks for reading and sorry for the long email > > -- > Marek > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Unify date format in Foreman and plugins
+1 on the format To make sure I am clear: 1) Dates will be stored in the DB as UTC. 2) Dates will be shown to the user based on their locale. Questions i have: a) If I enter a new date, am I entering it in my time zone? Assume serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12 April, what is stored in the DB? b) What preference/setting controls (2) -- bk On 04/12/2017 09:39 AM, Marek Hulán wrote: Hello, I'd like to suggest one recommended way of displaying date/time information on all pages. We started a discussion in a PR [1] that would change the format for config reports, please take a look there for possible solutions. After a discussion with Roxanne (cc) on another page we agreed on following form to be the best "April 10, 2017 17:08". So no timezone, no seconds, time is localized in current user timezone. Users can quickly see how long it was before so we didn't display the "x y ago" information. We could add it to tooltip if needed. Once nice thing about this format is that Rails provide helper to generate it. One could use something like <%= l(report.last_report_at, :format => :long) %> which prints "April 10, 2017 17:08". The month name and potentially the format is localized based on current user locale. So before I start sending PRs to various places, I'd like to know if we can all agree on one form, ideally the suggested one, and try to use it where it make sense. Please vote either in here or in the linked PR. The list of various places and formats in Foreman and plugins: * Core * reports page - reported at column: "about 1 month ago" dashboard page: "Generated at 12 Apr 12:41" facts - reported at columns: "about 1 year ago" trends page: "Last updated 1 day ago" audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" hosts - last report column: 2 months ago smart proxy - logs - time column: "11. 4. 2017 18:52:31" smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years" * Plugins* discovery - last facts upload: "1 day ago" openscap reports: "about 1 month ago" tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 12:49:00 UTC" rex - jobs: "about 19 hours ago" rex - logs: "2017-04-11 19:48:09 +0200" katello - last checking, registered at: "2017-04-12 11:42:06 UTC" katello - content host tasks: 4/12/17 1:42 PM Katello would probably need to implement the rails helper (or whatever format we chose) in their UI helpers. Hopefully that's something easy to do. [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 Thanks for reading and sorry for the long email -- Marek -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Unify date format in Foreman and plugins
Hello, I'd like to suggest one recommended way of displaying date/time information on all pages. We started a discussion in a PR [1] that would change the format for config reports, please take a look there for possible solutions. After a discussion with Roxanne (cc) on another page we agreed on following form to be the best "April 10, 2017 17:08". So no timezone, no seconds, time is localized in current user timezone. Users can quickly see how long it was before so we didn't display the "x y ago" information. We could add it to tooltip if needed. Once nice thing about this format is that Rails provide helper to generate it. One could use something like <%= l(report.last_report_at, :format => :long) %> which prints "April 10, 2017 17:08". The month name and potentially the format is localized based on current user locale. So before I start sending PRs to various places, I'd like to know if we can all agree on one form, ideally the suggested one, and try to use it where it make sense. Please vote either in here or in the linked PR. The list of various places and formats in Foreman and plugins: * Core * reports page - reported at column: "about 1 month ago" dashboard page: "Generated at 12 Apr 12:41" facts - reported at columns: "about 1 year ago" trends page: "Last updated 1 day ago" audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25" hosts - last report column: 2 months ago smart proxy - logs - time column: "11. 4. 2017 18:52:31" smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years" * Plugins* discovery - last facts upload: "1 day ago" openscap reports: "about 1 month ago" tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 12:49:00 UTC" rex - jobs: "about 19 hours ago" rex - logs: "2017-04-11 19:48:09 +0200" katello - last checking, registered at: "2017-04-12 11:42:06 UTC" katello - content host tasks: 4/12/17 1:42 PM Katello would probably need to implement the rails helper (or whatever format we chose) in their UI helpers. Hopefully that's something easy to do. [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751 Thanks for reading and sorry for the long email -- Marek -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Weekly Dev/Design Meeting: Facts and Trends
https://docs.google.com/document/d/1tQvpYYzPRoIwlWEGa5oaB248gD-zSs7IwLlG31Xzfo0/edit Facts and Trends Presented by Marek Title of Fact Values|Host name is inconsistent, but also inconsistent throughout the application. A global solution should be brainstormed. Can the nested items all be floated to the top in the table instead of forcing a user to drill down or perhaps a different layout to accommodate the nested items (folder icon, chevron, etc.) Use chevron instead of colons for breadcrumbs Action icon - convert to word button instead of icon. Load for chart does not use spinner. Legend text is small. Empty page should follow PatternFly start page. This page looks like they (the user) did something wrong. Is there an action that can be given on this page or craft a more detailed message. Move towards new PatternFly Datavisualization charts. (https://rawgit.com/patternfly/patternfly/master-dist/dist/tests/area-charts.html) “Trends for the last 30 days” layout can be improved to be more consistent with the other UI’s. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Organization titles in CLI
On úterý 11. dubna 2017 14:30:50 CEST Tomas Strachota wrote: > Thanks, i get it now. It's also viable solution. > One complication is that we would need to find a way how to deprecate > current usage of --parent in update commands and replace it with > --new-parent. But it's probably more consistent with how katello works Sounds reasonable to me -- Marek > > On Tue, Apr 11, 2017 at 1:51 PM, Andrew Kofink wrote: > > Correct. If there are 2 orgs with the same name under different parents, > > then not specifying `--parent` would result in an error such as "More than > > one record found". > > > > On Tue, Apr 11, 2017 at 7:08 AM, Tomas Strachota > > > > wrote: > >> I'm not sure I understand. It is currently possible to update parents > >> of organizations. Did you mean to use the parent parameter as a > >> compound identifier together with names? > >> > >> i.e. for changing a name and a parent you would use: > >> $ hammer organization update --name Brno --parent EMEA --new-name Krno > >> --new-parent ... > >> > >> and for info: > >> $ hammer organization info --name Brno --parent EMEA > >> > >> Did I understand it correctly? > >> > >> On Mon, Apr 10, 2017 at 6:12 PM, Andrew Kofink wrote: > >> > Tomas, > >> > > >> > Would it be easier to print the parent with list/info commands and > >> > allow > >> > updating that attribute (i.e. --parent/--parent-id)? We already have a > >> > handler in the ID resolver when multiple records are returned when only > >> > one > >> > is expected, though the error message does not tell the user how to > >> > further > >> > filter the results. > >> > > >> > - Andrew > >> > > >> > On Mon, Apr 10, 2017 at 11:09 AM, Tomas Strachota > >> > > >> > wrote: > >> >> I recently found out hammer uses only short names for identifying > >> >> organizations. Names aren't globally unique, which makes it impossible > >> >> to modify or delete an org when there are two of the same name but > >> >> nested under a different parent org. See [1] for details. > >> >> > >> >> I opened a preliminary PR [2] that adds option --organization-title to > >> >> all commands that consume taxonomies and a column "Title" to output of > >> >> the list command. This is simple solution, consistent with how it > >> >> works in hostgroups, but I don't think it's the best from the > >> >> usability point of view. Both options --name and --title as well as > >> >> table column labels feel redundant (columns contain the same data if > >> >> orgs aren't nested). > >> >> > >> >> An alternative approach is to completely replace names with labels in > >> >> hammer internally. We would have to change id resolver and let the > >> >> list commands print titles (in a column labeled "Name"). That's how > >> >> it's displayed in UI. > >> >> > >> >> Pros: > >> >> - users wouldn't notice the change, it should be seamless in most > >> >> > >> >> cases > >> >> > >> >> - no need to add extra options > >> >> - consistent with the UI, where column labeled "Name" contains > >> >> > >> >> titles in taxonomy tables > >> >> > >> >> Cons: > >> >> - name isn't the same as title and it might not feel natural to > >> >> > >> >> update > >> >> > >> >> as: > >> >> hammer location update --name 'emea/brno' --new-name 'krno' which > >> >> > >> >> would then be displayed as 'emea/krno' > >> >> > >> >> The con I mentioned could be fixed by checking if a user passed a name > >> >> containing '/' and using only last part of title in such cases. That > >> >> would make even --new-name 'emea/krno' work. > >> >> > >> >> Theoretically it could be used also for changing organizations parent. > >> >> --name 'emea/brno' --new-name 'europe/krno' would change parent to an > >> >> organization with title 'europe' and rename to 'krno'. But that's > >> >> maybe too much. > >> >> > >> >> How do you find the alternative approach? Do you see any other options > >> >> how the commands could work? Any idea is welcome. > >> >> I'd like to change hostgroup commands to use the same style and make > >> >> it consistent across the whole cli when we find a good solution. Are > >> >> there any commands in plugins (looking mainly at hammer-cli-katello) > >> >> that use resources with nested names? > >> >> > >> >> T. > >> >> > >> >> [1] http://projects.theforeman.org/issues/19157/ > >> >> [2] https://github.com/theforeman/hammer-cli-foreman/pull/299 > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "foreman-dev" group. > >> >> To unsubscribe from this group and stop receiving emails from it, send > >> >> an > >> >> email to foreman-dev+unsubscr...@googlegroups.com. > >> >> For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > Andrew Kofink > >> > akof...@redhat.com > >> > IRC: akofink > >> > Associate Software Engineer > >> > Red Hat Satellite > >> > > >> > -- > >> > You received this message because you are subscribed to the Google >
[foreman-dev] Heads up: Use ApplicationRecord base for your models
Heads up! Ivan merged my patch that changes behavior of how orchestration is logged. Previously it was logging everything into sql logger which is usually turned off by default as it is flooding logs. Since orchestration logs are very important I made a change which made possible to redirect orchestration logs into "app" logger. https://github.com/theforeman/foreman/commit/4deab2f313841e4283469ce9faafc0cdf1775720 The patch which was merged introduces new class ApplicationRecord (inherits from ActiveRecord::Base) which is something that will be in Rails 5 anyway and adds Foreman custom logger so all our logs from ActiveRecord objects goes into app logger but all SQL related stuff goes through ActiveSupport notifications into logger called sql. This is what we want. So new models must inherit now from ApplicationRecord rather than from ActiveRecord::Base. I filed a PR into Katello and Discovery, please update your plugins. It's not a breaking change so if you keep using ActiveRecord::Base plugin will usually work just fine but logs will keep ending up in the wrong logger making debugging more difficult. Unit tests passed locally and on jenkins (http://ci.theforeman.org/job/test_develop/2772/) but Ori reported this error after pull: PG::UndefinedTable: ERROR: relation "application_records" does not exist It looks like some gems are not compatible with ApplicationRecord, looks like it must be some old or custom gem or Foreman plugin that has some kind of dependency. ApplicationRecord is an abstract class, it must be treatened differently. More details here: http://stackoverflow.com/questions/37771127/rails-5-pgundefinedtable-error-relation-application-records-does-not-exi Report here if you encounter issues after git pull, bundle update and migration. In that case I recommend cleaning RVM environment and installing just the gems which are required by Foreman. You need to identify which gem is breaking it, unfortunately this is a bit hard to track down. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
