Improving terminology of Void/Unvoid and Retire/Unretire

I have started to work on this JIRA issue:

In it, @darius has suggested the following:

  • void -> Delete
  • unvoid -> Restore
  • retire -> Disable, Retire, or Deactivate
  • unretire -> Re-enable, Unretire, or Reactivate
  • purge -> Delete forever

We need to decide the best match for the retire and unretire. Personally I would like deactivate and reactivate . Lets try to find out the best option over here. Your ideas are welcome on this issue to complete this issue.

This has been a longtime in the queue.

1 Like

I concur with your suggestion and also like deactivate and reactivate. It makes logical sense to me.

So shall we go with this combination?

  • void -> Delete
  • unvoid -> Restore
  • retire -> Deactivate
  • unretire -> Reactivate
  • purge -> Delete forever

@darius what do you think? Is the time (2 days) enough to decide this?

Next step is to do some research with implementers/users about which pair of options to go with for retire and unretire

Having this posted here for two weekend days isn’t sufficient to count as “research with implementers/users” (or even long enough to presume that people have read this and thought about it yet).

I’d also especially appreciate any feedback from implementers and not developers like Robby and I…

One thing: I wrote this ticket in 2011, but since they we’ve built an entirely new OpenMRS 2.x Reference Application. So, at this point I think we should move this ticket to the RA project in JIRA, and only make these changes in Reference Application 2.x (mainly in the Admin UI module, I think). We shouldn’t make this kind of a sweeping change to the Legacy UI anymore.

1 Like

For me, it doesn’t matter what it’s called, so long as it’s consistent (the same terminology is used everywhere). In my quick look at the Reference App, it seems Retire/Unretire are used, so for simplicity, I would suggest just making sure that is used everywhere. Perhaps I feel this way because I’ve already learned what retire and unretire mean. Hearing from some new implementers would be beneficial. @ngoel2 and @jmpango, any suggestions from your perspectives?

Remember, the documentation and screen shots will need to be updated as part of this ticket where changes are made.

1 Like

This just concerns display text/verbiage, correct, not the change of any underlying DB tables or API methods? Since the webapp is now the “legacy webapp”, are we talking about making the changes there, or just in any reference app UI pages?

I think we should only make these changes in the Reference Application.

Whoops. Sorry for not reading closer. :slightly_smiling:

I could live with “Deactivate / Reactivate”, but I favor the terms “Retire / Unretire”, since, to me, these better communicates the notion that something that once was in use is no longer in use. “Deactivate” suggests that something was previously activated, which is often not true. Also, “Deactivate / Reactivate” implies something that can simply be toggled between active & inactive states; whereas, “Unretire” more correctly implies it’s an unusual action. And, as @arbaughj points out, we’ve been using “Retire / Unretire” so it will take less work to ensure we’re consistent.

Just my 2¢.

1 Like

I could live with keeping Retire/Unretire as terminology, because it’s less work.

(But we definitely need to change Void/Unvoid to Delete/Undelete.)

That said, I’d want to get some feedback from someone outside of the OpenMRS bubble as to whether “retire” makes sense in this context.

I’m new, and didn’t really have a problem understanding Retire/Unretire as terminology. It also makes sense from the point of view of “retiring” user accounts. It makes sense to keep it consistent, and I tend to agree with @burke

I kind of actually like void/unvoid, coz “delete” has a scary “you will never see this data again” implication, but that’s just my personal opinion. I got used to void/unvoid quickly and its more consistent with the terminology used in the data model.

For me, Retire/Unretire is part of me.that is the combination that works for me

1 Like

Looking at the feedback up to now, it is clear that the Retire/Unretire is the terminology preferred by existing and new users. Looking at the user experience point of view, it really doesn’t matter as far as we keep the consistency with these terms.

So shall we move on with changing Void/Unvoid to Delete/Undelete.

Adding my 2cents, though it seems odd to use the term undelete instead of restore, it is more consistent and intuitive to use “Undelete” in understanding the concept. WDYT?

Retire/unretire is good.

I like delete/restore, as I originally said on the ticket (and not undelete like I said in a comment on this thread)

You may proceed with working on this. Note that, as mentioned in this thread, these changes should be made to the Reference Application, and not to the legacy UI. (I don’t remember if we updated the ticket or not.

-Darius (by phone)

Noted it. I will update the ticket as well.

So I will use delete/restore for void/Unvoid.


Just to note, that Admin UI module seems to be using the proposed terminology already. Or have I missed something. Can someone please clarify?

I went through all the modules used in reference app and verified that the proposed terminology is used everywhere in uis and messages. Please review PRs below. Additionally if we are to back-port these PRs please let me know. Hope we can close this ticket now, unless openmrs-core needs to be updated with this terminology in other languages.


1 Like

Thanks for doing this, but, unfortunately, I don’t think we want to make these changes to the appointment scheduling module–see my comments on the ticket for more info.


@mogoodrich thank you very much for looking in to this. I replied in the ticket. :slight_smile: :