| Project: | ProjectPier |
| Version: | 0.8.5.0-Beta1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | GameGod |
| Status: | open - needs more info |
Jump to:
Description
Since there is no way to preview a message (yet! it would be for another feature request), I end up editing my messages many times. And each time, it adds a line in the activity log.
One solution (besides being able to preview the message) could be to add the activity log item only if the last editing was done more than a few hours or a day before... It could be configurable but I don't think it would be very useful though. Let's say it could be configurable by modifying the code :)
I really think we should have a preview feature. Especially for people who are using Textile code in their messages it would be quite handy to be able to see what your marked up text looks like before submitting it.
It would make sense indeed to add first the preview and then this one.
Anyway, for this one, does 15 minutes sound like a good time to ignore the edits?
I was thinking about that and I think that if a message is edited *by the same person* less than 15 minutes after the creation or last edit, it shouldn't be added to the Application Logs.
The number of minutes should be added as a config_option.
I suppose it should be universal to all objects, rather than specific to each kind of object. Would there be any reason why one would want to add all the edits for files but not messages (for example) actually?
Adding this "feature" sounds more like a hack job around an annoying deficiency. We should fix the deficiency (previewing messages/comments/etc.) instead of adding this annoyance work-around. :)
It seems to me like both could/should be done. Even if you preview the entry, you might want to add/change/remove something within the next few minutes.
Preview (maybe ajaxable) is required
About activity - better to make tracker of last created|edited objects than ignoring repeatable mesages
Not really. Both should be done. I think preview is mainly used to quickly check wether all the formatting, like lists, headings etc., look right. However, it is still likely, that you discover some typo or minor ommission shortly after the message was posted. In that case the edit should not be logged. (Or filtered from the log view).
Edit: ;)
This was in reply to TheWalrus
I will be adding a WYSIWYG TinyMCE editor patch within my GUI UPDATES bundle very shortly, but I will not work be touching the 15 minute log item aspect.
IMO the more configuration the better. Some users want many additonal feautures same want a simple version.
I'd be wary about adding a wysiwyg editor - I tried to add one in my wiki patch but Ryan told me to take it out...
I think the reason behind this is a WYSIWYG editor requires javascript and generates html markup. Textile does not generate html nor does it use javascript, meaning all browsers support it and the stored data is more secure (relatively).
With those assumptions in mind I am going to instead look for a wysiwyg editor that generates textile markup and install that instead or look look for a possible customization of tinyMCE (only because of tiny's wide support and it's ability to work in opera :-D )
I wasn't even aware when using PP that textile was available, nor what it was. A lot of active features aren't being appreciated due to lack of presentation.
Also editing the source of the problem (previewing) is better than coming up with a hack that also interferes with the system logic to address one of the symptoms (over-populated history) which may be necessary when relevent (not repeats)