removeField doesnt seem to work

[afdzal3]

Bug report

What I did

create protected function setupShowOperation()

add this
$this->crud->removeField('deleted_by');
CRUD::removeField('deleted_by');

What I expected to happen

column deleted_by shouldn't appear in show page

What happened

column deleted_by still appear

What I've already tried to fix it

Is it a bug in the latest version of Backpack?

After I run composer update backpack/crud the bug... is it still there?
Yes

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

PHP VERSION:

PHP 7.3.28-1+ubuntu20.04.1+deb.sury.org+1 (cli) (built: May 1 2021 11:54:39) (
NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.28, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.28-1+ubuntu20.04.1+deb.sury.org+1, Copyright (c) 1999
-2018, by Zend Technologies

LARAVEL VERSION:

v8.60.0@44f16a31a1d4ac8a51605550d7796e2273984a48

BACKPACK VERSION:

4.1.52@239e60df0436f8a817facce20a2dffcb2b6e7250

[welcome]

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

[tabacitu]

Hey @afdzal3 ,

This might be connected to a known bug in the Show Operation. One that unfortunately we cannot fix without a breaking change, and plan to fix in Backpack 4.2. Basically the problem is that you cannot remove the columns that have been added by the ShowOperation using setFromDb(), because that's called after your definition.

I have two possible solutions for you:

Solution 1

There's a workaround to hiding columns in the Show operation that should work, when this doesn't. You can specify 'visibleInShow' => false (or ->visibleInShow(false) if you use the fluent syntax) in your setupListOperation() definition for that column, and it should hide it in Show.

Solution 2

See my comment here please - #3108 (comment) - you can disable the setFromDb() in the Show operation and manually specify all the columns (or call setFromDb() yourself but where it's ok to do so).

---

Sorry for the bad experience, I know this bug sucks, but unfortunately we can't fix it until we launch a new version. Otherwise we'd be breaking everybody's admin panels, and that would suck even more...

I'm going to close this, as I'm pretty sure #3132 fixes it, but if I'm mistaken and the solutions above don't work for you, or the PR doesn't fix the problem or something, please let us know and we'll reopen the issue no problem.

Cheers!

Other notes:

• this issue seems to be the same as [Bug] removeColumn() doesn't work in setupShowOperation() #3108
• the PR that fixes this known bug is [4.2] Move Show operation setup in its own method #3132
• there's a PR here to also be able to give a closure to visibleInShow() - will also be merged in 4.2; but for now it only supports true/false;

[pxpm]

Just a note to @afdzal3 , you are trying to use fields in ShowOperation but you should use columns as in ListOperation.

Apart from that @tabacitu rationale is correct.

Best,
Pedro

[tabacitu]

Oh yeah... also... that... 😅