MARCcat: MARC Bibliographic records (UXPROD-786)

[UICAT-62] Lock of the record during cataloguing workflow Created: 24/May/19  Updated: 19/Jan/21  Resolved: 19/Jan/21

Status: Closed
Project: ui-marccat
Components: None
Affects versions: None
Fix versions: None
Parent: MARCcat: MARC Bibliographic records

Type: Story Priority: P2
Reporter: Annalisa Di Sabato Assignee: Mirko Fonzo
Resolution: Won't Do Votes: 0
Labels: MARCcat-Bib, block_record, cap-mvp, edit_record, marccat, team-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File screenshot-1.png    
Issue links:
Requires
is required by UXPROD-904 MARC Bib record - Creation of new bib... Closed
is required by UXPROD-906 MARC Bib record - Creation of new bib... Closed
Sprint:
Development Team: @cult
Epic Link: MARCcat: MARC Bibliographic records

 Description   

If the user is editing a record, another user can't edit the same record. The system will display a warning message to notify to the user that the record is locking by another user.



 Comments   
Comment by Cate Boerema (Inactive) [ 24/May/19 ]

Annalisa Di Sabato and Christian Chiama can we move this bug out of UXPROD into another project and assign the correct development team? Thanks!

Comment by Annalisa Di Sabato [ 27/May/19 ]

Hi Cate,

this bug is related to our internal need to lock a record in MARCcat. This means that if a librarian is editing a record in MARCcat, this record will be locked for all other MARCcat users (so another user will not be able to edit the same record in MARCcat at the same time). It refers to an already existing WeCat control function. We just need to port it to MARCcat.

If you're referring to the possibility to lock a record in general (I mean while a librarian is editing a record via MARCcat, another librarian cannot edit the same record via Inventory) in both cataloging applications (Inventory and MARCcat), I can open a new issue and please tell me which is the correct development team to assign it to.

Comment by Cate Boerema (Inactive) [ 29/May/19 ]

Annalisa Di Sabato usually development bugs and stories do not get filed in UXPROD which is primarily for planning (epics and features). There isn't even the possibility to assign a development team to a bug in UXPROD which means this bug is unassigned. This results in problems with reporting, for example, on the bug statistics dashboard. Do you have a development project you can move this into?

Bug statistics dashboard: https://folio-org.atlassian.net/secure/Dashboard.jspa?selectPageId=10402

Comment by Annalisa Di Sabato [ 30/May/19 ]

Ok, Cate thanks and sorry for the misunderstanding. Give me some times and I'll move all bugs opened by me to another project,

Thanks

Comment by carmentrazza [ 02/Apr/20 ]

The issue was worked on on the back-end.
Examples of calls for creation and deletion of the lock:
Example PUT in Edit of the record
http://127.0.0.1:8081/marccat//bibliographic-record/lock/6592177?userName=diku_admin&uuid=124589637899656633&type=R
Example DELETE in save of the record
http://127.0.0.1:8081/marccat//bibliographic-record/unlock/6592177?userName=diku_admin&uuid=124589637899656633&type=R
It must be worked from the front end.

Comment by Annalisa Di Sabato [ 24/Apr/20 ]

Carmen has concluded her part for this issue (estimated 18 h).
The issue now is assigned to Matteo (he has estimated 8 h).

Comment by Annalisa Di Sabato [ 06/May/20 ]

Matteo asked Mirko to include some modifications in a patch:

"edit insertable data type for the uuid recordlock column"

Comment by Mirko Fonzo [ 06/May/20 ]

The issue has been fixed in the MARCcat DB patch 1.4.
It is possible to perform a test in our test environment.

Comment by Matteo Pascucci [ 18/May/20 ]

Call implemented 90%, response management is missing. The service must return a message or the parameters used for the lock

Generated at Fri Feb 09 00:18:10 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.