-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Per field type apperance in the revisions history view. #12
Comments
Hello there! Thanks for opening your first issue on this repo! Just a heads-up: Here at Backpack we use Github Issues only for tracking bugs. Talk about new features is also acceptable. This helps a lot in keeping our focus on improving Backpack. If you issue is not a bug/feature, please help us out by closing the issue yourself and posting in the appropriate medium (see below). If you're not sure where it fits, it's ok, a community member will probably reply to help you with that. Backpack communication channels:
Please keep in mind Backpack offers no official / paid support. Whatever help you receive here, on Gitter, Slack or Stackoverflow is thanks to our awesome awesome community members, who give up some of their time to help their peers. If you want to join our community, just start pitching in. We take pride in being a welcoming bunch. Thank you! -- |
Hi @mamarmite this looks like a great improvement for Sure it would be better to have a visual representation of a checkbox, instead of; In some cases it may not make sense to have a visual representation of the field, but in many it does, and yes, there could be a system where we check if there is a blade to represent that change, if it doesn't, we print the raw text. I like the idea 👌 |
I've accomplish some advancement in that feature, but still in project context. I need to test it in 4.2 and implement it as in the package scope. If someone have time, I can push all the things done at this point, to start from or to refactor from. |
I love the mockup/screenshot @mamarmite . Totally agree that would be better than what we have now, in most cases I think the value is very short, and it doesn't make sense to have so much visual clutter for it. Should test with big values too (textarea etc) I think you meant
|
Yes, I meant column, I used the field because in my mind they are the only modifiable elements, which can have revision to it. Good idea to use the configured column there. |
Feature Request (more of a concept presentation before beginning implementing it)
What's the feature you think this package should have?
Have per field type view as we show revisions. Like a view for text, longtext, dates, dates range, images, etc.
Have you already implemented a prototype solution, for your own project?
Nope, I'm in the process of designing the logic, the algorithm.
Pretty like the fields algorithm of the CRUD, it would print changes with the field appearance.
Like with a fields folder with field blade's views.
For now in my current project, I only check the length of froms and tos, and show the big space (by default with the package) and that view if it's a small changes, like a date range, a varchar, etc.
Do you see this as a core feature or an add-on?
I would see it as a core feature, but I'm in no place to say that. I think it should follow the same design as the crud's field. Maybe overkill ?
The text was updated successfully, but these errors were encountered: