[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Adding more stages to approval workflow?



Hi Chris, hi John,

one follow up question. I got my complex net of different states 
working, but I can't get the filters on the "manage deposits" page to 
work. I reduced the new statuses to one for this example.



I can't check the "Status 1" checkbox. It always stays unchecked. Having 
eprints in that state or not does not change anything. The same problem 
occurs when I use the unedited dark_archive code from the Bazaar. Can 
you give me a hint, why this might not work?

Regards,
Johannes


> Hi Chris, hi John,
>
> I think I got a working demo by now. I used the dark_archive plugin as 
> a start, and added a second stage so ...
>
> inbox/buffer/... -> dark_archive -> dark_archive2
>
> ... is now possible. The final workflow will be more complex, but I 
> think I should get it configured with this approach.
>
> Thanks again,
> Johannes
>
>
>> Hi Chris, hi John,
>>
>> thanks a lot for your quick replies and your hints! I'll take a look 
>> at both solutions and let you know if I got it all to work.
>>
>> Regards,
>> Johannes
>>
>>
>>> There is a different way to achieve this.
>>>
>>> You can add new 'eprint_status' options.
>>>
>>> This page: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FBuilding_a_DataSet&data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=YruIfY%2BFXc%2FsLRq2ZLwNXahNuKr68Blqh6o1QvKkrw0%3D&reserved=0 provides 
>>> details of how to create a 'dark archive' - which is normally a 
>>> different end-point for a record - so instead of:
>>>
>>> Inbox -> buffer -> archive
>>>
>>> You can also go:
>>>
>>> Inbox -> buffer -> dark_archive
>>>
>>> This plugin does the same:
>>>
>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbazaar.eprints.org%2F401%2F&data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&sdata=tOBkIFcms6R171MJXL%2BpzhtnZ9Ob20OTGo9lF2Xdzzg%3D&reserved=0
>>>
>>> What you would need to configure is
>>>
>>> options => [qw( inbox buffer archive deletion bufferX bufferY )],
>>>
>>> and also think about whether anyone can move e.g. from buffer to 
>>> archive - or whether everything has to go through all stages.
>>>
>>> You may want to define more user roles - so a 'normal' editor can 
>>> move from buffer to bufferX, but a 'super editor' can move from 
>>> buffer to bufferX, bufferY or even to archive.
>>>
>>> You may also want to create a clone of the review screen that looks 
>>> at bufferX and buffer explicitily.
>>>
>>> Chris' solution would also work, each has it's merits!
>>>
>>> Cheers,
>>> John
>>>
>>> *From:*eprints-tech-bounces at ecs.soton.ac.uk 
>>> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] *On Behalf Of 
>>> *Christ?pher Gutteridge via Eprints-tech
>>> *Sent:* 26 June 2019 12:06
>>> *To:* eprints-tech at ecs.soton.ac.uk; Johannes Schultze 
>>> <schultze at effective-webwork.de>
>>> *Subject:* Re: [EP-tech] Adding more stages to approval workflow?
>>>
>>> This isn't trivial but would be possible. This is me riffing and 
>>> would need refining.
>>>
>>> First of all, I would add tickbox fields for levels of signoff. ie. 
>>> signoffA and signoffB and? signoffC.
>>>
>>> Next I would use conditionals on the "workflow" XML file to modify 
>>> it as follows.
>>>
>>> In the main <flow> section, use a <when> condition to split 
>>> behaviour for the 3 stages of the buffer to add additional stages to 
>>> the end IF the user has the appropriate parameters. At an extreme 
>>> level you can write a plugin function that takes the user and eprint 
>>> as inputs and returns true if they have the right to approve it at 
>>> stage a/b/c.
>>>
>>> If signoffA is false and the user can approve level A on this 
>>> EPrint, they see the levelA approve stage which has the signoffA 
>>> tickbox on it and they can set it to true.
>>>
>>> If signoffA is true, but? signoffB is false and the user can approve 
>>> level B, the see the levelB approve stage which has the signoffB tickbox
>>>
>>> Similar for signoffC.
>>>
>>> The validation for publishing makes "signoffC" approval a required 
>>> field so it can't be published without signoffC being set.
>>>
>>> <flow>
>>>  ? <stage ref="type"/>
>>>  ? <stage ref="files"/>
>>>  ? <stage ref="core"/>
>>>  ? <stage ref="subjects"/>
>>>  ? <epc:choose>
>>>  ???? <epc:when test="eprint_status='buffer' and !signoffA and $current_user{canSignoffA}'>
>>>  ??????? <stage ref="signoffA" />
>>>  ???? </epc:when>
>>>  ???? <epc:when test="eprint_status='buffer' and signoffA and !signoffB and $current_user{canSignoffB}'>
>>>  ??????? <stage ref="signoffB" />
>>>  ???? </epc:when>
>>>  ???? <epc:when test="eprint_status='buffer' and signoffA and signoffB and !signoffC and $current_user{canSignoffC}'>
>>>  ??????? <stage ref="signoffC" />
>>>  ???? </epc:when>
>>>  ? </epc:choose>
>>>  ?</flow>
>>>
>>> This is utterly untested but gives some ideas I hope. Documentation 
>>> here:
>>>
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEPrints_Control_Format&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=YDvmAqFq9dX3x8YsTr9kvulvqgCjzjbz704hmIoeE3k%3D&amp;reserved=0 
>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEPrints_Control_Format&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=YDvmAqFq9dX3x8YsTr9kvulvqgCjzjbz704hmIoeE3k%3D&amp;reserved=0>
>>>
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FWorkflow_Format&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=uJxmPFmzIOs%2FaW6PLy5WR6KAApdt%2BNHKAkCUJfyfq%2FI%3D&amp;reserved=0 
>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FWorkflow_Format&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=uJxmPFmzIOs%2FaW6PLy5WR6KAApdt%2BNHKAkCUJfyfq%2FI%3D&amp;reserved=0>
>>>
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEPScript&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=nJBxrnTO80Ye3uVi6JcK51J5mKBIPdyJ0V8dlPcFe7E%3D&amp;reserved=0 
>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEPScript&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=nJBxrnTO80Ye3uVi6JcK51J5mKBIPdyJ0V8dlPcFe7E%3D&amp;reserved=0>
>>>
>>> It's possible to make custom EPScript functions to do more complex 
>>> tests.
>>>
>>> On 26/06/2019 11:05, Johannes Schultze via Eprints-tech wrote:
>>>
>>>     Hi all,
>>>
>>>     I'm currently evaluating EPrints as a replacement for an old repository
>>>
>>>     (custom made). Until now everything worked fine (import of existing
>>>
>>>     files and metadata), and I'm now trying to get the release/approval
>>>
>>>     workflow configured. As far as I have read in the documentation, there
>>>
>>>     are four stages by default:
>>>
>>>     inbox -> buffer -> archive -> deletion
>>>
>>>     I would need some more levels (and roles) in the approval workflow.
>>>
>>>     Something like this:
>>>
>>>     inbox -> buffer1 -> buffer2 -> buffer3 -> archive -> deletion
>>>
>>>     Different roles in the hierarchy of the organisation should approve the
>>>
>>>     submitted eprint in multiple steps. Is it possible to configure such
>>>
>>>     behaviour in EPrints? Or can something like this only be implemented
>>>
>>>     with some kind of plugin?
>>>
>>>     Regards
>>>
>>>     Johannes
>>>
>>> -- 
>>> Christopher Gutteridge<totl at soton.ac.uk>  <mailto:totl at soton.ac.uk>  
>>> You should read our team blog athttp://blog.soton.ac.uk/webteam/
>>
>>
>> -- 
>> Dipl. Inf. Johannes Schultze
>> Gesellschafter / Entwicklung
>>
>> Tel. +49 40 60940857-5
>> Fax. +49 40 60940857-1
>> schultze at effective-webwork.de     
>> effective WEBWORK GmbH
>> Neuer Wall 18
>> 20354 Hamburg
>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.effective-webwork.de&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=h6%2FbuPKDfJVB5QLmAwgke2L4Y725z1GrfbUt%2F3Su1lE%3D&amp;reserved=0
>>
>> GF Dr. Matthias Finck
>> HRB 101108 (Hamburg)
>> UStId DE254169943
>
>
> -- 
> Dipl. Inf. Johannes Schultze
> Gesellschafter / Entwicklung
>
> Tel. +49 40 60940857-5
> Fax. +49 40 60940857-1
> schultze at effective-webwork.de     
> effective WEBWORK GmbH
> Neuer Wall 18
> 20354 Hamburg
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.effective-webwork.de&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=h6%2FbuPKDfJVB5QLmAwgke2L4Y725z1GrfbUt%2F3Su1lE%3D&amp;reserved=0
>
> GF Dr. Matthias Finck
> HRB 101108 (Hamburg)
> UStId DE254169943


-- 
Dipl. Inf. Johannes Schultze
Gesellschafter / Entwicklung

Tel. +49 40 60940857-5
Fax. +49 40 60940857-1
schultze at effective-webwork.de
effective WEBWORK GmbH
Neuer Wall 18
20354 Hamburg
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.effective-webwork.de&amp;data=01%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7C6e8a5fd40ce04736566908d70f67f36c%7C4a5378f929f44d3ebe89669d03ada9d8%7C0&amp;sdata=h6%2FbuPKDfJVB5QLmAwgke2L4Y725z1GrfbUt%2F3Su1lE%3D&amp;reserved=0

GF Dr. Matthias Finck
HRB 101108 (Hamburg)
UStId DE254169943

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20190723/5a11467c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbfkcpdgfdkmldbh.png
Type: image/png
Size: 19091 bytes
Desc: not available
Url : http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20190723/5a11467c/attachment-0001.png