Facility Address missing from prescriptions

Glad you found your issue but I’m confused.(no news there!). In essence whenever facility is changed any user associated with that facility has to be re-saved, Is that the jest?

That is what I have encountered.

May be an attempt at security or just a bug but, too me, I vote bug. I don’t understand the purpose of the behavior however I’m sure it will come up again. I’ll look at after fixing statements.

Agree with the bug assessment :slight_smile:

I was able to re-create and appears that it is only after you alter the facility name but, any other edits are okay so, it makes sense now. Will go ahead and auto update user table unless this may violate some clinical protocol dealing with provider credentials. Hopefully someone will let me know if this is so.

New PR #988 to resolve this issue.

Thanks for the fix and just brought it into the codebase.
-brady

Thanks for your quick solution to the issue in the future. Unfortunately, it doesn’t address it right now in the present. We are currently using 5.0.0(3). Where would this code go?

In interface/usergroup/facilities.php , could run the query directly for 5.0.0:

sqlStatement("UPDATE users SET facility=?  WHERE facility_id=?", array($newFacility['name'], $newFacility['fid']))

Brady,

I tried adding sqlStatement suggested to the facilities.php file but it did
not work for me.

Sherwin

Place it between line 62/63:


(needs to be within the Editing existing facility section)

also will need to change the query to:
sqlStatement("UPDATE users SET facility=? WHERE facility_id=?", array(trim($_POST['name']), trim($_POST['fid'])))

Thanks, @brady.miller:

@juggernautsei What’s that suppose to mean!

There are times when I am following a thread looking for an answer to a problem. Then the thread suddenly stops. Or, in the information, the writers say it works but don’t say what worked. Or, says thanks and I try the solution on the screen and it doesn’t work for me. I can go on but the point being @robert.down put the check box so that when we have clear solutions to a problem. It would make it easier for users to find those answers.
My aim was to make sure there was a clear solution. I was stepping out of the developer role and playing the role of someone who knows very little or no code. So, I was asking questions in that manner.
No offense intended.

I am sorry I didn’t back port my fix but I’m so use to being on git tip I don’t look back. Sometimes I don’t fully read the thread which I will remedy. No offence taken.

1 Like

Just an FYI, if you paste a link on a newline on the forums it’ll automatically create a “onebox” link. See below

yep, I replied because I mistakenly assumed the backport would be super simple. It’s currently not frequently straightforward to bring stuff back to 5.0.0 (this is a good thing, though, and means there’s been a lot of work done on the codebase; also means that it is time to start thinking about planning for release of 5.0.1, so then won’t need to worry as much about backporting :slight_smile: )
-brady

Not entirely true because there are those that are still using 4.2.2 because it is stable and reliable to them. They won’t upgrade to the latest and greatest ever because there is always the possibility of things not work right as we have seen recently.

But I know what you mean about back porting. It will have to be up to the ones that are behind to back port a fix if the error exist in the version being used by them.

3 posts were split to a new topic: Version life cycle