Skip to content
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

Open
mamarmite opened this issue Feb 10, 2021 · 5 comments
Assignees

Comments

@mamarmite
Copy link

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.

Exemple d'une rangé simple

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 ?

@welcome
Copy link

welcome bot commented Feb 10, 2021

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:

  • Bug Reports, Feature Requests - Github Issues (here);
  • Quick help (How do I do X) - Gitter Chatroom;
  • Long questions (I have done X and Y and it won't do Z wtf) - Stackoverflow, using the backpack-for-laravel tag;
  • Showing off something you've made, asking for opinion on Backpack/Laravel matters - Reddit;

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!

--
Justin Case
The Backpack Robot

@promatik
Copy link
Contributor

Hi @mamarmite this looks like a great improvement for revise-operation.

Sure it would be better to have a visual representation of a checkbox, instead of;
image

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 👌
If you have the time, PR's are welcome 🙌
I'll move this to v4.2 since we are now in feature freeze mode, and I'll let @tabacitu and @pxpm give their opinions on this.

@mamarmite
Copy link
Author

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.
I don't know yet, when I'll be able to finished this. This spring I hope.

If someone have time, I can push all the things done at this point, to start from or to refactor from.

@tabacitu
Copy link
Member

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 columns, though, right? That the before/after value is shown in a different way depending on the column type (not field type). I'm asking that because it makes more sense to me to use the columns:

  • they're not editable, just for show
  • they can be inferred pretty easily with CRUD::setFromDb() (though it's not recommended)
  • most likely they're already defined in a different operation (like List of Show) so Revise can just take the configured column types from there

@mamarmite
Copy link
Author

Yes, I meant column, I used the field because in my mind they are the only modifiable elements, which can have revision to it.
Just to push that in this issue, I implemented (only my project scope for now) to the style as shown in #6
With bootstrap's classes to mimic the milestone style without having to load another structure to the css.

Good idea to use the configured column there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants